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PREFACE 


The purpose of this Contractor Report (CR) is to present a model for ‘Engineering the 
System and Technical Integration.’ Aspects of the model draw information from several of our 
other publications and from other sources, which is necessary for completeness. Therefore, this CR 
contains material that is intentionally repeated in summary form from these sources. The sources 
are referenced for those who want to probe deeper into the subject. 
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CONTRACTOR REPORT 


ENGINEERING THE SYSTEM AND TECHNICAL INTEGRATION 







I. Introduction 


Space exploration is very challenging. Meeting the challenge requires extremely high 
performance systems that are complex, with interactions that are very difficult to predict. A 
major lesson we have learned is that 80% of the problems that have occurred are not due to a 
lack of understanding of the primary engineering disciplines of the system and subsystems, but 
are due to a breakdown in Engineering the System and Technical Integration. Said in a 
different context, it is a breakdown in communications. From a unpublished white paper edited 
by Dr. Wiley Larson: “Complex systems typically fail because of the unintended consequences 
of their design." [ Larson, et. al, “The Art and Science of Systems Engineering”]. We must 
therefore understand that everything acts as a system; nothing acts independently; it is a 
whole, where all the parts interact, many times in unexpected and unpredicted ways. The 
question faced is “How do we understand and manage these complex, highly interactive 
systems”. 

This report will make a cursory look at the various elements of how programs and 
projects understand and manage engineering the system and technical integration. 

Considered first is the challenge of space flight and the major lessons learned while meeting 
the challenge. The report then discusses the process of how we accomplish a total design and 
operation of a space system with primary emphasis on launch vehicle systems. The major 
thrust of the report is: Design and operation of a space project is a total system. It must have 
proper attention to integration in all aspects of its characteristics and the processes used, 
including leadership and management, in order to achieve a balanced and successful project. 
The balanced system is always a compromise between conflicting requirements and 
paradoxes that must design the system to preclude all potential failure modes within the 
operating conditions while carrying out of the functions of the system. Robust communications 
is one of the keys to the process, as is the evolving of derived requirements as the system and 
its subsystems interact to perform the mission. Many of the principles and illustrations shown 
herein are extracted from the handouts of the courses we teach for MSFC: Space Launch and 
Transportation Systems (SLaTS) and Lessons Learned in Engineering. [Blair, Ryan, and 
Schutzenhofer, 2011] Other detailed information can be found in other publications as 
referenced. 
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II. The Challenge of Space Flight / Meeting the Challenge 


A. The Challenge 

The physics of flying into space demands that maximum energy be extracted from the 
chemical energy source, that light but high strength structures be developed, and that the 
system and element losses be minimized. The transformation from potential energy to kinetic 
energy pushes the limits of current propulsion system technologies. The same is true for the 
efficiency of the structure or dry mass of the system. In addition losses that occur in terms of 
how we fly the system must be stringently managed and controlled. In other words we can just 
barely make orbit with the technologies available today. These factors result in a requirement 
for high performance, high power density systems that drive large sensitivities and unwanted 
interactions. At the same time we must preclude failures in the system while carrying out its 
major functions and missions. [Blair, Ryan, Schutzenhofer,and Humphries, 2001.] 

As a result space launch vehicles must have high performance that drives complex 
interactions, and pushes the limits of our knowledge and the application of basic physics 
principles. As Dr. Rick Fleeter so eloquently pointed out [Fleeter, 1998], “A very wise professor 
of mine once proved the existence of God. He explained that if you look at the energy required 
to get into earth orbit, a function of the earth’s mass and the gravitational constant, and 
compare it with the energy of chemical bonds which break and remake to create rocket 
propulsion, it turns out to be just barely enough to get into orbit. Slightly weaker chemical 
bonds or a deeper gravity well and we’d be locked down upon earth’s surface. Slightly weaker 
gravity or tighter molecules and going into orbit could be as easy as “launching” a Cessna 150. 
Only a God interested in challenging us could have engineered the improbable circumstance 
of barely possible space travel (When I said this professor was very wise I wasn’t kidding).” 

Current technology just barely enables us to make orbit. In other words we must have 
very efficient propulsion and structural systems and understand and manage all the system 
losses at a very high proficiency. We have seen in the past that a propulsion system or 
structural system technology advancement shows great promise of increasing the efficiencies, 
lowering cost and compressing schedule, yet when integrated into the system it produces 
interactions that greatly reduce the expected gains. In general the introductions of these more 
efficient technologies also increase cost and schedules, just the opposite of what is desired. In 
addition to meeting the technical challenges is the challenge to meet a reasonable 
development schedule with affordability/cost efficiencies. The following summarizes the 
challenge for the launch vehicle with some illustrations of the magnitude of the efficiency of the 
various elements. [Blair, Ryan, and Schutzenhofer, (SLaTS Course), 2010] 

Launch vehicle design is a challenge of highest order 

• Payload size and mass drive launch vehicle performance requirements. 

• The vehicle must impart orbital energy to the payload. 

(Orbital energy is large — for~160 n.m. altitude, AV -25,300 ft/s) 
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• With current technology, this pushes propulsion, structures, materials, and systems 
capability to the limit. 

• Affordability with schedule efficiency impose additional challenges. 

For example: 

Propulsion: 

• Efficient conversion of chemical potential energy to kinetic energy (The Space 
Shuttle Main Engine has an l sp of 452s out of a potential of about 460s. If the 
Shuttle system was designed for 460s, this change would result in a 25% growth 
in the fuel tank volume. Thus, an l sp of 460s would not result in a vehicle 
providing maximum payload capability.) 

• Thrust to weight ratio at liftoff greater than 1 .1 . To obtain this thrust level 

The Saturn F-1 engine chamber pressure is P c =1000psi; The Space Shuttle Main 
Engine (SSME) chamber pressure is P c =3000psi. The increase in chamber 
pressure of the SSME over the F-1 increases the static/dynamic flow induced 
loads by at least a factor of three. 

• Figure 1 puts the challenge in perspective by comparing the power density of 
common transportation engines with the Space Shuttle Main Engine (SSME). 
Plotted is horsepower per pound for an auto engine, Indy Race Car Engine, 

Small Jet Engine, Large Jet Engine and the SSME. Notice that the car engine 
has a ratio of 0.54 while the SSME has a ratio of 879. If an average car engine 
could be built to the same power density and efficiency as the SSME it would 
weigh about 1/4 of a pound. 

Structures: 


• Efficient (lightweight and strong) structures result in a vehicle mass fraction of 
around 0.90 (the ratio of propellant to total mass). For example the ratio of the 
average skin thickness to the diameter of the Shuttle External Tank is a factor of 
3 less than that of an aluminum drink can. 

System Effects: 

• Losses during mission must be minimized (Understand, quantify, control, and 
manage). The main source of the losses is the presence of complex interactions 
which have their source in the high performance requirements. 

In addition to the challenges delineated above the system is further challenged by the 
following considerations and activities: 

• Precluding failure of the system and subsystems while carrying out their functions and 
missions (Constant emphasis on identification of failure modes and their mitigation). As 
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Dr. Henry Petroski has said, “The best way to prevent failure is to understand failure.” 
[Petroski, 2008] 

• Integrating schedule efficiency and affordability/cost into the technical issues stated 
above, thus balancing the total system. The balancing is a compromise between 
conflicting requirements. 


Engine Power Density Comparison 

Horsepower / Pound 


Shuttle Engine BK II 
7,480 lb 
6,574,215 HP 
HP/lb = 879 



Figure 1: Power Density Comparison of Transportation Systems Engines 

[SLaTS Course, Chapter 1, 2010] 

All of this high power density and high efficiency comes with a price. There are many 
problems that occurred in the SSME that can be shown to be a direct result of the high 
performance requirement. The basic characteristics of the fuel turbopump illustrate these high 
power density requirements. For example the turbine blades that power the pump are about 
the size of one’s thumb, yet during peak performance times each turbine blade generates 
about 550 horsepower, which is at least twice the power of an automobile engine. Achieving 
this performance leads to high temperatures and pressures that present a major challenge to 
the design and the development of materials that can endure the environments. In addition, 
complexity is another factor that must be considered in the design of high performance 
systems. In his book, Robert Pool, [Pool, 1997] says that the complexity factor leads to most of 
the failures and is very difficult to predict. He also concludes that this results not only in 
technical complexity, but in organizational complexity as well. 
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High performance requirements lead to high power densities and large sensitivities. 

This requires in-depth understanding and intricate balancing of the system to achieve success. 
The combination of high performance, high power densities, sensitivities, and complexity 
results in the need for project managers to have a high octane, efficient organization. 

The application of the principles of Engineering the System and Technical Integration 
results in constant need for decision making. These decisions have impacts throughout the 
total project life cycle. The following are some quotes that deal with decisions that entail the 
sensitivities, interactions, and failure modes. 

• “When you put energy into a system you can never choose what kind of changes shall 
take place and what kind of results remain. All you can do, and that only within limits, is 
to regulate the amounts of the various changes. This you do by design” [Pye, 1969] 

• “The requirements for design conflict and cannot be reconciled. All designs for devices 
are some degree failures... The designer or his client has to choose to what degree and 
where there shall be failures.” [Pye, 1969] 

• “All structures will be broken or destroyed in the end. Just as all people will die in the 
end. It is the purpose of medicine and engineering to postpone these occurrences for a 
decent interval. The question is: What is to be regarded as a decent interval?’” 

[Gordon, 1988] 

• “Cooperate with Mother Nature to the maximum extent possible; minimum energy 
solutions are almost always the most reliable.” [Junkins, 2001] 

• “To understand what engineering is and what engineers do is to understand how 
failures can happen and how they can contribute more than successes to advance 
technology.” [Petroski, 2008] 

As stated initially the major lesson we have learned in dealing with these high 
performance systems is: The problems experienced in meeting the Space Exploration 
Challenge have not been a breakdown in the understanding of individual disciplines of our 
work but in a breakdown in the application of Engineering the System and Technical 
Integration. 

Recently the Deputy Assistant Secretary of the Air Force for Science, Technology, and 
Engineering asked the National Academies to study the project acquisition failures and make 
recommendations for solutions. [National Research Council, 2008] Some of the major findings 
are: 


1 . The committee believes that the accumulation of processes and controls over the 
years - well meant of course - has stifled domain-based judgment that is 
necessary for timely success. 

2. The creation of a robust systems engineering process is critically dependent on 
having experienced systems engineers with adequate knowledge of the domain 
relevant to a contemplated program. 

3. The committee said there were six drivers of cost, development time, and 
performance risk. They call these factors the six seeds of failure. They are 

• Inexperienced leadership 
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• External interface complexity 

• System complexity 

• Incomplete or unstable requirements at Milestone B 

• Reliance on immature technology 

• Reliance on large amounts of new software. 

In looking at major failures of NASA systems, five root causes have been identified: 

1 . Shifting from engineering “hands on” and “excellence” to “insight/oversight”. 
Lack of ownership. 

2. “Normalization of the deviances”. Not questioning anomalies. 

3. Lack of critical thinking. Over-reliance on procedures and computer codes. 

4. Decentralization of authority. 

5. Organizational and technical complexity. 

These root causes and recommended remedies are summarized in a later section of the report 
(Section IV.H, Achieving Engineering Excellence). 

B. Meeting the Challenge 

Meeting the challenge of space flight includes 

• High efficiency propulsion systems 

• Dry mass efficiency 

• Efficient management of system losses 

• Effectively dealing with systems interactions 

• Precluding failures 

• Affordability/Cost 

• Efficient development schedule 

These are major issues all aerospace projects are facing in today’s environment and culture. It 
is mandatory that these systems have a short development time and be affordable. Defining 
affordability usually means determining how much the political system will appropriate. 

Considering the above references and our experiences, the following sections will 
address what we think is one of the better ways of dealing with the challenge. In general we 
call the process Engineering the System which includes Technical Integration and Classical 
Systems Engineering. 

The challenge can be met using the approach outlined below on Figure 2. Notice that 
objective of the system has many components of the challenge such as performance, 
affordability/cost, schedules, and reliability/safety. The challenge is met by balancing the 
uncertainties, sensitivities, interaction and margins. This balancing of the system is always a 
compromise between the conflicting requirements, subsystem optimization versus system 
optimization and many of the derived requirements. The balancing is achieved by having a 
design process to design the product and an operational process to build and operate the 
product. This is implemented through leadership and management, which is the enabling 
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framework. Finally the operating foundation of all the processes for meeting the challenge is 
the triad of integrity, communications and relationships. It should be pointed out that each of 
these areas comprise sets of major activities, processes and principles within themselves 
requiring more time and space to address than is possible within this report. 


Space Exploration Challenge 

The challenge of space flight is to conceive \ design } build and operate , safely \ high 
performance, high power density', highly interactive Space Systems at reasonable 
costand schedule efficiency. 

The Solution 


Uncertainties 


Performance 

Sensitivities 


Affordability/Cost 

Interactions 


Schedules 

Margins 


Reliability/Safety 




Balancing 

Risks 


Enabling 

Framework 


Integrity 


Operating 

Foundation 


Communications Relationships 


Figure 2. Process for Meeting the Challenge of Space Flight 


NASA has published their top level model for Engineering the System as NPR 123.1 A 
focusing on the various program phases [NASA Systems Engineering Process and 
Requirements, 2007], Figure 3 is the basic approach showing the relationship between 
requirements and the realized products. Figure 4 depicts the relationship between the various 
reviews and the program phases. 
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Figure 3. NASA’s System Engineering Process 

[NASA Systems Engineering Process and Requirements, 2007] 
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Figure 4. Program Reviews and Product Program Phases 

[NASA Systems Engineering Process and Requirements, 2007] 



Our model, developed before the initiation of this NASA model, serves as a model for 
Engineering the System during the Formulation and Implementation Phases. There are many 
other models such as the Vee and the International Council of Systems Engineering (INCOSE) 
models that some use for this work. All have some merit and should be studied as an adjunct 
to our model. The rest of the report will be a discussion of the elements of Figure 2 that a 
project manager must understand and manage to have a successful product. The organization 
required to implement these principles and functions takes many forms and depends on the 
individual project situation therefore it is beyond the scope of this report. 
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III. Engineering the System 


It is the responsibility of the Project Manager to bring about the overall development of a 
successful product that meets the challenges described above. We call this Engineering the 
System. To set the stage for understanding the Engineering the System model we will first look 
at a typical set of functions a project or program manager must perform. (Figure 5) 
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Figure 5. Program or Project Manager’s Functions 

The functions of a project manager are separated into six main categories: 1 . Technical, 
2. Business/Project Control, 3. People and Organizational Management, 4. External 
Relations, 5. Operating Environment, and 6. Ancillary Products. In this report we will mainly 
deal with the Technical category which contains the function of Technical Integration and is 
subdivided into (a) Classical Systems Engineering, (b) Design and Analytical Integration, (c) 
Hardware/Software Integration, and (d) Operations. The following sections will deal with these 
and other functions from a top-level viewpoint. In summary the project manager must 
formulate, maintain approval, implement and evaluate across all these functions from both the 
specialty and the integrated system standpoint. 

This report will be primarily concerned with the Technical function; however, proper 
execution of the Technical function must interact with the Business, External Relations, 
Operating Environment and other functions to achieve the best balanced technical solution. 
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A. Technical Integration and Classical Systems Engineering 


• Technical Integration is typically the integration of Design and Analysis, Hardware and 
Software, Operations, and Classical System Engineering along with interactions of 
Business, External Relations, Operating Environment and other functions to create a 
system with acceptable performance that is safe, reliable, and affordable. 

• Classical System Engineering provides the processes, manages the documentation, 
reviews, and configuration control for the Technical Integration function. 

The typical functions of each are: 

Technical Integration 

• Design 

• Analysis & Test 

• Trade Studies 

• Build Hardware 

• Develop Software 

• Verification & Validation 

• Operations 

• -ilities 


Classical Systems Engineering 

• Processes 

• Planning 

• Requirements Tracking 

• Reviews 

• Configuration Control 

• Verification & Validation Tracking 

• Documentation 

There can be various ways of relating Technical Integration and Classical Systems 
Engineering, as shown on Figure 6. Figure 6 shows a top-level sketch of some of the models 
used for integration. In fact what we have observed is that most of these forms of the model 
create an overemphasis of classical system engineering and de-emphasis of technical 
integration, sometimes losing it altogether. However, it should be pointed out that any of these 
models can be made to work with the proper leadership and management making sure that the 
system process is balanced. We think that the preferred model of Figure 6 best represents the 
true balance of the technical functions. 
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Figure 6. Technical Integration Models 

A similar interpretation is given in Reference [Larson, et. al., 2009] by Schaible, Scolese 
and Ryschkewitch, who write that, “Systems Engineering is not only about the details of 
requirements and interfaces among subsystems. ...Similarly, accurate control of interfaces and 
requirements is necessary to good SE, but no amount of care in such matters can make a poor 
design concept better. Systems engineering is first and foremost about getting the right design 
- and then about maintaining and enchancing its technical integrity, as well as managing 
complexity with good processes to get the design right. ...For our purpose, we divide SE into 
technical leadership and its ally, systems management. 

• Technical leadership focuses on a system’s technical design and technical 
integrity throughout its lifecycle 

• Systems management focuses on managing the complexity associated with 
having many technical disciplines, multiple organizations, and hundreds or 
thousands of people engaged in a highly technical activity 

...To succeed we must blend technical leadership and systems management into complete 
systems engineering.” 
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The situation is complicated by the complexity of systems and the compartmentalization 
done in the design process for design efficiency (to be discussed in more detail in later 
sections). We in general handle compartmentalization by defining and managing information 
and interfaces; however, when we reintegrate the parts back into a system, interactions occur 
which are very difficult to predict. Quoting from Pool, “More importantly, complex systems are 
not completely predictable. No one knows exactly how a given design will work until it has 
been built and tested-and the greater the complexity, the more testing it needs. ... In truly 
complex systems, no amount of testing or experience will ever uncover all the possibilities, so 
decisions about risky technologies become a matter of how much uncertainty one is willing to 
put up with and how much one trusts the designers.” 

“The complexity that marks modern technology is not merely a matter of how many 
pieces are part of the system. Indeed, that is not even the most important factor. Instead, the 
defining feature of a complex system is how its parts interact. By contrast, the components of a 
complex system interact with others, and the actions of any one component may depend upon 
what others in the system are doing. The more interaction among the components, the more 
complex the system, and the harder it is to predict what the system will do from knowing how 
any given components will perform. The more complex a system, the more difficult it is to 
understand all the different ways the system may behave- and in particular, to anticipate all the 
different ways it may fail. Interdependence among parts creates entirely new ways that things 
can go wrong, ways that engineers often overlook or ignore. Thus many technological failures 
chalked up to mechanical breakdown or design flaws are more accurately described as the 
children of complexity.” [Pool, 1997]. Our experience parallels Poole’s observations and says 
that we must manage the interactions as well as the information flow and the interfaces. 

Designing complex systems entails many decisions throughout the process. The 
decisions are always a balancing act composed of trades based on taking some of what you 
don’t want in order to get some of what you do want. Figure 7 illustrates the process of 
evolving requirements and design through trades and balancing the system out, which always 
involves compromise. 
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Compromise 



Balanced Design 



Figure 7: Space System Design is a Compromise 

It is imperative that we take a systems design/balancing approach across all aspects of 
the life cycle. This is necessary in order to meet operability, cost, and other goals in addition to 
performance. Otherwise the system obtained is driven by performance requirements and the 
impacts are accepted in the other programmatic areas such as cost, schedule and safety. 

The goal we endeavor to meet is: While achieving necessary safety, obtain the best 
balance among performance, the -ilities, and affordability/cost. The success of a launch 
system is measured not only by its physical performance parameters such as how much 
payload it can lift to orbit, but by its reliability, its operability, how much it costs, and numerous 
other attributes. A successful system must be designed from the start for these “-ilities” and 
costs as well as for physical performance. To accomplish this goal it is necessary that 
functional relationships between the parameters of design and the -ilities be established. While 
it is a challenge to obtain these functional relationships, we must work toward making the - 
ilities and cost concurrent “design-to” attributes along with performance, as illustrated on 
Figure 8. 
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Figure 8. Lifecycle Design from a Systems Viewpoint 


B. The Scope of a Project: Lifecycle Awareness Considerations 

The first aspect to managing a project requires that the manager and the organizational 
system have a constant awareness of the lifecycle of the project and where it is in the cycle 
(Figure 9). The awareness and the resulting management approach must be from a total 
systems viewpoint. Developing the architectures, refining the concepts, and performing 
preliminary and detail design is an integrated whole which considers all aspects of the life 
cycle that then can be implemented during the phases shown on the chart. [The total lifecycle 
process including the final operating process is sometimes called a product design. Alternate 
terminology designates design as the process of producing specifications.] 
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Figure 9: Project Lifecycle Flow 


Although Figure 9 depicts the elements of the life cycle progressing in a linear manner, 
there are many feedback loops and iterations that occur within the process as the design 
evolves. The main elements of the life cycle are summarized in the following. 

1. Requirements 

Life cycle starts with requirements of the initial mission objective. Derived from these 
top-level mission requirements is a set of baseline requirements, designated derived 
requirements. Derived requirements constitute the great majority of the requirements on the 
project. They must consider the total life cycle and cover all design aspects; therefore their 
derivation initially is highly iterative but converges to the set of baseline requirements. 
Requirements decomposition and development of derived requirements are addressed in a 
later section of the report. 

Pugh says that “the requirements are the mantle of the design.” Requirements should 
be verifiable and must be under strict control by the project. Constraints and requirements 
must be constantly under review and challenged since they determine what the product will be. 
As Pugh and others have said, many if not most of the requirements conflict and result in 
trades, which balance these conflicts in the best manner possible; however in the end you 
always get some of what you don’t want in order to get most of what you do want. [Pugh, 1994] 
Figure 10 summarizes these characteristics and show that it is always a major iteration 
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process. One word of caution: make sure the requirements are not so constraining that there is 
no room left for the creativity of the engineer and designer to determine the best solution. 


Requirements are the mantle that determines the product’s 
characteristics, both good and bad. 

- Must be challenging with minimum constraints 

- Minimum change 

- Minimum required to maintain order 

- Leave room for creative design 

(do not dictate the design) 


-Define and allocate 
-Trades/sensitivities 
- Converge requirements 
and Concepts (iterate) 


requirements - 



Constraints must be defined and evaluated, because they 
greatly alter or compromise a design. 


Figure 10. Summary of the Characteristics of Requirements and Constraints 

2. Architecture Generation 

Using these top level requirements, the various functions the system must perform are 
determined, from which is derived a group of potential architectures that can perform the 
functions. These architectures are for the total system and include for a launch system the 
launch vehicle, payloads, manufacturing, operations, logistics, communications etc. Through a 
process of evaluation the potential architectures are narrowed down to a handful, for which the 
concept development and selection process is started. 

3. Concept Development and Selection 

Concept Development adds detail and fidelity to the candidate architectures to better 
determine their characteristics and enable an informed down-selection. Initially, mass 
estimating relationships and sizing programs are used to achieve closure on a configuration. 
The system and subsystems then are defined in greater detail to meet their requirements 
considering natural and induced environments. More detailed evaluations lead to the selection 
of one or more concepts to be carried to Preliminary Design. These concepts are for the total 
system, including the vehicle design, manufacturing and verification plan, and concept of 
operations. 
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Figure 1 1 is Pugh’s model for the convergence of the concept selection and the 
balancing of requirements. As you deal with the options of the concept you are also dealing 
with tailoring the requirements. As this process converges it arrives at the balanced concept 
and requirements. 


4. Preliminary Design Definition 

The purpose of preliminary design is to provide greater assurance that the concept is 
capable of meeting requirements. (In general there is only one concept to carry through 
preliminary design; however, there are cases where two concepts are carried through the initial 
part of the PDR phase.) To achieve these results, the fidelity of the configuration is increased 
and refined; in addition, the significant subsystems and their requirements are defined. The 
depth of penetration of trade and sensitivity studies is increased through analyses, tests, and 
simulations. Then the requirements, risk, cost, reliability, safety, operability, schedule, and TRL 
are refined and reassessed. Interfaces, interactions, pertinent tests, top-level verification plans, 
and preliminary facility and GSE requirements/concepts are defined and the fidelity of the 
project plans and documents is updated. Preliminary design can occur in iterations as 
concepts are down selected following each iteration until the best concept remains. This 
concept then goes to detail design. At the completion of preliminary design, there is a 
preliminary design review (PDR). At the completion of PDR, the concept becomes the baseline 
and is ready for detail design. 


Requirements / Constraints 


Generate Architectures 



Figure 11. Balancing Requirements and Concepts, Pugh Model 

[Pugh, 1994] 
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5. Detail Design Definition 


The purpose of detail design is to provide drawings and specifications for all the 
hardware and software of the fully analyzed, developmentally tested, and simulated system 
that can be manufactured and operated within cost and flown with an acceptable risk. The 
performance, cost, reliability, safety, operability, schedule, and technology readiness attributes 
of this system must satisfy the mission statement, requirements, and constraints. At the 
completion of detail design, there is a review called the critical design review (CDR). 
Additionally, plans are updated for final development, manufacturing, verification, and 
operations. 

6. Materials and Manufacturing 

The design properties of a material system are contingent on the manufacturing 
processes employed, both in the primary production, secondary shaping, and assembly phase. 
Accordingly, the design functions of materials and manufacturing have been historically linked. 
Their interdependence in the modern era has been magnified by the rapid expansion in the 
development of both new materials and new processes. 

Composite materials, including metallic, nonmetallic, and combinations thereof, are 
examples of advanced structural material systems that challenge traditional design 
methodology. Many such systems require the development of design properties specific to 
individual component shapes. This differs from most metal alloy systems where the design 
properties for basic product forms (i.e. , sheet, plate, extrusions etc.) are readily available and 
apply independent of final component shape. When working with advanced structural material 
systems, it is often necessary to develop the manufacturing processes concurrent with the 
component design. The result is a “best fit” compromise between part configuration, weight, 
cost, and schedule. Assembly processes, such as welding and bonding which alter the 
properties of a material, also require special attention and clearly delineate the synergistic 
relationship between materials and manufacturing [Blair, Ryan, Schutzenhofer, and 
Humphries, 2001], 

7. Verification and Validation 

Verification and validation is one of the key tasks a project manager is responsible for, 
with the completion of the task providing the information of how well the hardware and 
software meets the requirements and it worthiness for flight/operations. We normally define 
verification and validation as: 

• Verification - Proof, by examination of objective evidence, that the product complies 
with specifications. 

• Validation - Proof, by examination of objective evidence, that the product 
accomplishes the intended purpose and is ready for a particular use. 

Verification and Validation may be determined by test, analysis, demonstration, inspection, or 
a combination of these. 
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8. Operations 


Launch operations can be considered in terms of mission and ground operations. In the 
following paragraphs is an overview of each. 

Mission operations are associated with planning, designing, and executing events for 
the launch vehicle to achieve mission success. This includes activities associated with 
prelaunch, launch, in-flight (including abort scenarios), on orbit, de-orbit, entry, landing, and 
recovery. Included in mission operations are the launch system communication process, as 
well as astronaut selection and training. 

Ground operations entail designing and managing a process that includes activities 
from transportation to training. Firstly, all major elements of the vehicle are received as 
transported from the manufacturers. Then each element must be processed to prepare for final 
vehicle assembly. For past and current NASA vehicles, final vehicle assembly takes place in 
the vertical assembly building (VAB) where system integration, checkout, and verification are 
completed. The cargo must be adequately processed with integration into the vehicle either in 
the VAB or on the pad. The vehicle is rolled out on the mobile launch platform. All of the launch 
pad facilities supporting the launch must be prepared, e.g. rotating service structure, noise 
suppression, etc. Then prelaunch operations include propellant loading, launch control center 
operations (Mission Control Center and Payload Operations Center), etc. In anticipation of post 
flight, preparations are made for landing, post landing, and depot maintenance. Execution of 
ground operations requires integrated logistics support and training and certification of key 
personnel. 

The goal throughout these life cycle phases is to conceive, design, build and verify a 
system, including the operational system, that can be operated in a safe and affordable 
manner and meet the objectives of the program. 

9. Iterations within the Process 

Although the Vee is not a part of NASA’s NPR on System Engineering, the following 
Figure 12 shows a detailed view of the left side of the classical Vee-diagram (amended) and 
illustrates where the requirements and design in the life cycle are addressed at each phase of 
the development process. While requirements and design development proceed down the left 
side of the “Vee”, the interacting issues of all life cycle phases are captured with vertical arrows 
depicting interactions. The level of fidelity needed will increase as you progress time-wise 
down the left portion of the “Vee”. Regardless of the model used for technical integration, this 
penetration must take place. 
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Design maturation 
is not linear but 
cyclical with 
penetration ever 
deeper at each 
stage of the design 
process with 
consideration for 
all project lifecycle 
phases 


Figure 12. Depth of Penetration and Considerations of Each Phase 

of the Vee Diagram 

[Forsberg, 2005] 

10. Mindsets of the Life Cycle Phases 

One very interesting aspect of the life cycle that the management team must also be 
aware of is that the mindset or the culture is different for all the different phases of the life 
cycle. For example: the phases of formulating, designing, and implementing an operational 
system each require a very different mindset/culture. Implementing an operating system is, by 
its nature, process and procedural focused. You must keep building and operating the system 
to the characteristics for which it was verified, which drives the culture to emphasize 
procedures and processes. Formulating the system needs much less emphasis on procedures 
and processes; here the emphasis is on innovation and creativity to conceive, trade and 
balance a total system for the performance, schedule, and cost of the total life cycle. 

Figure 13 shows an amended NASA System Engineering approach [NASA Project 
Handbook, 2008], with the final phase of validation including initial flight testing and the 
additional long term phase of operations, which is the E phase of NASA Standards. At the 
bottom of the chart is shown the general culture characteristics of each of the phases. An 
important management question this raises is; “How does the organization and culture change 
to accommodate these different life cycle phases with different functional emphases?” How we 
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manage across these different lifecycle phases is a major challenge, particularly if the 
proceeding programs were in the operation phases that generated a culture that wants to start 
the new program with the baggage of all the procedures and processes inherited from the past 
culture. 
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Figure 13. Lifecycle Characteristics with General Culture Attributes 

[NASA Project Handbook, 2008] 


11. Configuration Management 

Configuration management during life cycle is another important task. Ares I SRM 
Thrust Oscillation is a good example of the function: The thrust oscillation problem was 
discovered prior to PDR but not in time to find a solution and impact the configuration. The 
Project decided to complete the PDR using a frozen configuration without consideration of 
thrust oscillation and when the solution matured have a delta PDR of the design impacts to the 
PDR configuration. Project Integration not only managed the initial PDR, but also managed the 
development of the solution and its impacts through trade studies using uncertainties, 
sensitivities, margins, constraints and system impacts, followed by managing the delta PDR. 
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12. Project Review Content 


The reviews that occur at each major event of the lifecycle must be total systems 
reviews and include not only the documentation but have a major emphasis on the technical 
understanding and merits of the system as well as all the programmatic concerns of cost, 
schedule etc. The implication of the reviews is “understanding, understanding, understanding” 
and “communications, communications, communications”. Remember it is a System we are 
designing, building, verifying and operating. There has been some confusion and loss of 
purpose for these reviews as a result of findings from the Columbia Accident Investigation 
Board Report where NASA was criticized for “Power Point engineering” many of our critical 
issues with the Shuttle system. While this may be a valid finding, it does not negate the need 
for use of good presentations to develop and demonstrate the level of understanding of the 
integrated design details and to establish a framework to facilitate communications during 
these reviews. Over the last several years for many project reviews the process was focused 
on producing a collection of documents for review that were the subjective evidence of the 
design process but not on having good guided discussions of the integrated design issues. 
Another complaint is that the time required to develop these presentations takes away from the 
engineers doing "design work". While producing the presentations does take time, it is value 
added to the process because it forces a discipline on the presenter to communicate 
effectively and on the reviewers to understand and challenge the design. 


C. Technical Integration Process 

1. Process Model 

As part of a team at Marshall Space Flight Center we have developed a model for 
Technical Integration. The following is a short summary of the model which is discussed in 
detail in NASA TP-2001 -21 0992 [Blair, Ryan, Schutzenhofer, and Humphries, 2001]. This 
reference is for a launch vehicle design, but the principles and approach are generic and apply 
to any large system design. 

The process starts with requirements and some concept of the vehicle. The concept is 
compartmentalized first by hardware subsystems or elements. The central part of the life cycle, 
i.e., from Architectural Generation to and including Detail Design is enabled by 
compartmentalization and reintegration, see Figure 14. While compartmentalization is 
necessary to accomplish the design of a large system, it does add complexity. Initially, the 
process starts with the launch vehicle definition and ends with the total integrated system 
design. Firstly, the system is compartmentalized into subsystems (hardware/software pieces). 
This creates interfaces that have to be tracked via interface requirement documents (IRD) and 
interface control documents (ICD). Each subsystem is then compartmentalized into design 
functions that design the system and subsystem so that the attributes of the each meet the 
derived requirements. To achieve the design, the design functions are compartmentalized into 
disciplines. The disciplines provide design results determined from analysis, test and 
simulations. We can define this decomposition and reintegration process globally in terms of 
the transportation system or in terms of each of its major elements such as the launch vehicle, 
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verification system, operating system, manufacturing system etc. We will illustrate it in general 
using a launch vehicle; however, the process applies to the total system. 



Figure 14. Compartmentalization and Reintegration 

Thus the system is compartmentalized; now it must be reintegrated to obtain a totally 
integrated system design. Firstly, the disciplines are reintegrated. Adequate analyses, tests, 
and simulations are required to be accomplished. Then sensitivities, uncertainties, and 
margins need to be defined to provide information for risk assessment. Next the design 
functions are reintegrated. It must be assured that the attributes of the design meet the derived 
requirements. Furthermore, they are required to be verified. In addition, account of all 
interactions and nonlinearities has to be included. Finally, based on all knowledge of the 
design, a risk assessment is developed. This activity includes, at least, designers, disciplines, 
and S&MA. The final level of reintegration deals with subsystems and addresses interfaces. 
Specifically, the physical, functional, and informational flow across interfaces must be 
matched. Also interactions and nonlinearities related to the total system, in addition to those 
between subsystems, must be addressed. System integration and verification, operational 
constraints, and system risk are also considerations. 

A total integrated system design is achieved when compartmentalization and 
reintegration are completed. Reintegration requires interactive communication by all members 
of the design activity where the compartmentalized subsystems (sub-subsystems, parts, etc.) 
are designed and then reintegrated into a balanced system design that can be verified and 
validated to operate at a specified risk level. 

Further insights, i.e., “peeling the onion”, into the design process can be gained in 
consideration of Figure 15. Shown here is an illustration of subsystems and design functions. 
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In the middle of the figure is an example of a system and some of its subsystems. For 
example, follow the solid blocks; they go from the launch vehicle system to the propellant 
conditioning system. Each is designed by the design functions indicated with the dashed 
arrows. At the upper left is the system set of design functions (planes) and at the top of the set 
is the launch vehicle system design function. It is responsible for all technical aspects of the 
system design. That includes technical integration, classical system engineering, 
hardware/software integration, etc. In addition, the system design function orchestrates and 
integrates the design activities. In a similar fashion the top plane for each subsystem performs 
a similar activity. 
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Figure 15. Typical Subsystems with Associated Design Functions 


Integration of the system, design, and discipline functions is shown in Figure 16. The 
design functions are listed on the right of the figure. They provide the drawings, specifications 
and/or data books associated with each design function. For example, the aerodynamic design 
function provides the vehicle shape (outer mold line) and associated data books; 
trajectory/performance designs a balanced trajectory to achieve the target destination for the 
payload within all constraints, structures provides drawings and manufacturing specifications 
and so on. However, the system design function (plane) is responsible for all technical 
aspects of the system design. 

The vertical conduits labeled requirements, architecture, and philosophy indicate formal 
flow of the associated information and it is controlled by the system. The system design is 
achieved in an iterative fashion via the design functions. Initially, a small group composed of 
representatives from each design function evolve a conceptual design(s) after an number of 
iterations. As the design matures through the Design & Analysis Cycle (DAC) process, the 
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number of participants increases as well as the supporting data base. However the basic idea 
shown in Figure 16 remains in place but on a larger scale. The yellow conduit represents 
informal integration between the design functions and this is a key factor in achieving a 
balanced design. In addition, there is also significant informal integration within each design 
function. As the design converges, reintegration takes place and the converged attributes 
(green conduit) of the design formally flow to the system plane where they are eventually put 
under configuration control. If a balanced convergence with adequate margin can’t be 
achieved, more iterations may be required or some system level requirements may have to 
change. 



Attribute/Reintegration 
{Information Flow Up) 


Requirements 

(Information Flow Down) 


Architecture 

(Information Flow Down) 


Philosophy and Criteria 
(Information Flow Down) 


Informal Integration 
{Information Flow) 


Design Functions 
System 
Aerodynamics 
Trajectory/Performance 
GN&C 
Structures 
Thermal 
Propulsion 
Avionics 

Materials & Manufacturing 

Operations 

Other 


Figure 16. Technical Integration of System, Design, and Discipline Functions 

We have discussed the stack of design functions that are required to design a system or 
subsystem. Now consider the process that takes place within a design function (i.e., what 
happens on the design function planes). This is where the design functions are 
compartmentalized into discipline functions. As an example, consider the Structures design 
function shown in Figure 17. The block titled “Design” represents the structural designer on 
the CAD machine, who is responsible for taking the requirements, architecture, and philosophy 
from the Systems plane and synthesizing a structure that meets those requirements. In 
accomplishing this, he/she is supported by a number of discipline functions, some of which are 
illustrated on the diagram. These include Natural Environments, Materials, Thermal, Control, 
Loads, and Stress. These discipline functions perform analysis, test, and simulation of the 
synthesized design, and provide the necessary databases. Discipline functions also are the 
keepers of standards for their respective technical areas. 
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Figure 17. Structures Design Function with Discipline Functions and Decision Gates 

The discipline functions provide the designer with information necessary to determine 
the structural design that will meet requirements. This is a very iterative process that requires 
extensive communication among the parties involved. Typically the designer hypothesizes a 
design (geometry, materials, etc.) from his/her experience and imagination, informed by 
interactions with the discipline functions. The hypothesized design is analyzed to determine its 
attributes, which are compared with the requirements. 

The goal, of course, is to have the attributes match the requirements. This is shown 
diagrammatically as a single decision gate on the Structures design function plane. However, 
since there are multiple requirements to be met, there are multiple gates that must be 
successfully passed. Examples of these gates are shown on the diagram below the design 
function plane. They include attributes such as structural strength, endurance, and weight, 
accommodations of propulsion and thermal protection, and manufacturing and assembly 
compatibility. Along with these metrics the gates include cost and “-ilities” such as operability 
and other figures of merit required to assess the design. When the design has been iterated to 
the point that its attributes successfully pass all the gates, the Structures design function can 
feed the structural design and its attributes up to the System plane, where additional system 
attributes and interactions are assessed. With the completion of this assessment the drawings 
and specifications are output. 

This process obviously does not occur in one pass, but requires many iterations and 
tradeoffs. Design inherently is a balancing and tradeoff process. To arrive at an acceptable 
design, there are multiple tradeoffs and iterations among the discipline functions and the 
design functions. We will not achieve a successful design unless there is intensive interaction 
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and communication among all the participants. Iterations may also be required with the 
System plane, particularly if requirements relief or reallocation is required. 

An area of design process improvement that is needed is integrated system analysis 
where we would better unify the subsystems, design functions, and discipline functions that are 
currently compartmentalized (simplify the compartmentalization process). 

Designing for and managing interfaces is one of the keys to successful space products. 
There is a truism that says “Get the interfaces right and everything else will fall into place.” So 
the process starts with requirements that are derived to minimize the number and complexity 
of the interfaces and their functions. (See more detailed discussion in Section IVC3). As the 
compartmentalization process creates the need to manage interfaces between the 
subsystems, elements etc., the same is true for the information (includes data, assumptions, 
etc.) flow among subsystems and among the design functions and discipline functions. 
Input/Output matrices are useful tools to help manage this information flow. See Figure 18. 
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Figure 18. Matrices of Input/Output Information Flow 

The Ixl matrix. (Figure 19) is used for interface information flow among the subsystems 
and system, which are represented along the diagonal. Inputs to an element are on its vertical 
column and outputs are on its horizontal row. There are two types of information flow between 
the each pair of elements: requirements and approach to meeting the requirements. The first 
element provides its interface requirements to the second element, then the second element 
feeds back information on how those requirements are being met. This results in a clockwise 
flow of data. The matrix is a very handy tool to identify requirements, functions, and design 
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characteristics before one spends the time of writing IRDs and ICDs. Later sections will 
provide more details on interface management. 


Interfaces- 1 x I Matrix for Launch Vehicle 
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Figure 19. Interface Management Using the Ixl Matrix 


The same type device, called a data NxN, is used for information flow among design 
functions and discipline functions. This is a very powerful tool that helps keep track of the data 
and the meeting of requirements, as well as where each comes from and goes to. (Figure 20) 
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Figure 20. Information Flow NxN Matrix 

The other main concern is the interactions created by the reintegration of all of the parts 
that were compartmentalized. Interactions can be stable or unstable, linear or nonlinear and 
can be very destructive in nature. Some of the interactions are well understood and have 
clearly defined practices for elimination or making them safe. Some of the known interactions 
are: 

• Pogo 

• Aeroelasticity/flutter 

• Rotor machinery whirl 

• Structure/control interaction 

• Propellant sloshing 

• Dynamic tuning 

• Forced vibration 

• Avionics/thermal interaction 

• EMI/EMC 

Many interactions are very difficult to predict and some may be unknown. The solutions 
to eliminate or control each interaction will impact the system. As stated previously, 80% of 
the problems experienced in aerospace engineering are due to a breakdown in systems 
engineering/technical integration, with most being lack of understanding of interactions . It is 
mandatory that all interactions be understood, designed for and managed. 

There are other essential activities that are fundamental to the Technical Integration 
design process: Safety and Mission Assurance (S&MA) and Classical Systems Engineering. 
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Safety and Mission Assurance activities are an inherent part of the design activities. 
S&MA has three main components: (1) System Safety deals with hazard identification, 
detection, and mitigation; (2) Reliability identifies failure modes and causes, along with their 
associated probabilities. (3) Quality addresses process control and verification of the as-built 
hardware and software. 

As stated previously, Classical Systems Engineering provides the framework, process 
control, and documentation of the Technical Integration process. It can be represented by the 
classical Systems Engineering “Vee” that follows the design life cycle. 

Overall Technical Execution of the Design entails the integration of SM&A and 
Classical Systems Engineering into the Technical Integration process described above, as 
represented in Figure 21. 


Technical Execution of Design 




Figure 21. Technical Execution of Design 
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One great model for understanding technical integration is the “T-Model”. The T-model 
is shown in Figure 22 and is so named because of the horizontal and vertical components. It is 
a global model that focuses key features of technical integration. It delineates the system 
(horizontal) along with subsystems, design functions, or disciplines (vertical) while 
emphasizing the importance of formal and informal integration. 

The horizontal portion of the “T” represents the System. The upper level (above the 
dashed line) of technical integration has been known by interchangeable names as formal 
integration, system integration, or top level integration. The leader and his or her office are the 
primary facilitators or operatives at this level of integration. The emphasis of this technical 
integration is primarily related to the systems aspects of the design process, i.e., technical 
management, certification of the system, etc. The primary focus is delivering the product with 
the proper balance of performance, cost, reliability, safety, operability, schedule, and TRL. 
Balance is achieved via managing and resolving conflict. All system related decisions and all 
system related technical conflicts are respectively made and resolved at this level. In addition, 
all system planning, control, and documentation is maintained at this level. 

Technical integration below the dashed crossbar is informal and is a key enabler of 
achieving a successful design. It is given by interchangeable names of subsystem, design 
function, or discipline to subsystem, design function, or discipline integration (there are a 
number of combinations of these interactions), informal integration, or in-depth integration. The 
emphasis here is informal interactions (communication) between and among subsystems, 
design functions, or disciplines while including the system perspective. It can be hall-talk, 
phone calls, inter-office discussion, technical interchange meetings, etc. or other forms of 
communications. Since there are many vertical legs that affect each other, informal 
interactions among these elements are critical. The functional organizations are the primary 
operatives of integration for discipline-to-discipline aspects of the design process, while the 
engineering design functions are the primary facilitators of integration for the subsystem-to- 
subsystem specific aspects of the design process. The vertical legs of the “T” represent 
activities (designs, analyses, tests, simulations, etc.) associated with subsystems, design 
functions, or disciplines. They signify in-depth knowledge (in the vertical direction) but with a 
system perspective. This in-depth knowledge is required to be accurate and with the 
associated uncertainty defined. 

A classical example of the T-Model is the game of basketball, which is both a team 
sport and an individual emphasis sport. The vertical legs are the fundamentals of the game 
such as passing, shooting, dribbling, footwork, hand and finger position on the ball, screening, 
blocking etc. For example, basketball is played with the ball being controlled with the fingertips, 
not the cup of the hands. Footwork is first played on the ball of the feet and movement is by 
shifting without crossing the legs except in special situations. In guarding an individual you in 
general don’t slap down on the dribbler but slap up or to the side otherwise you get called for a 
foul. The systems part is both formal and informal. The formal takes place by the team running 
patterns and then informal is taking advantage of what the defense does such as the back 
door, or the pick and roll. There are many formal plays also such as jump ball and out of 
bounds situation etc. 
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Figure 22. Classical T-Model for Technical Integration 


The basic functions and characteristics of the T-Model for technical integration were 
discussed above. Depending on the approach used, the functions of the formal and informal 
aspects shift dramatically. Figure 23 illustrates two approaches to how much emphasis is given 
to formal integration. A highly formal technical integration approach greatly reduces the 
functional role of the informal integration. In our opinion moving in this direction greatly 
impedes the technical integration function. 
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Figure 23. T- Model Technical Integration Options 
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The bottom line for managing integration is communications, communications, 
communications. 

2. Examples of Historical Technical Integration Issues 

This section will discuss two problems experienced in space exploration as illustrations of the 
complexity of integration. Discussed are: 

Skylab Solar Array System Venting Failure 
Space Shuttle Aerodynamics Anomaly 

Skylab Solar Array System Venting Failure 

There have been at least three similar venting incidents in the history of space flight. 
Two resulted in the loss of the vehicles and one crippled the payload. Those lost were the 
Atlas-Able-Pioneer (1959) and the Atlas-Centaur (1966). The one crippled was the Saturn 
Skylab (1973). The similarity in these incidents was that each had a shroud that came off 
during the transonic flight regime. In the first two incidences, the understanding of the flow 
physics was not known. Had it been known, the shrouds would have been designed so that 
they would have been under crush loads; however that was not the case. They were 
unknowingly designed so that during transonic flight the shroud load was a burst load that 
resulted in failure. These failures could have been prevented had the shrouds been adequately 
vented. 

In the case of the Saturn Skylab an auxiliary tunnel was not adequately vented. The 
venting analysis was predicated on the assumption that the tunnel would be completely sealed 
at the aft end, but the aft end as manufactured was not sealed. The openings in the aft end 
were a result of lack of “technical integration.” The fact is this critical sealing requirement had 
not been communicated between aerodynamics, structural design, and manufacturing 
personnel, see [Lundin, 1973]. Furthermore, “system engineering” was not adequate. There 
was no dedicated systems engineer and that resulted in lack of effective integration. 



Figure 24. Saturn Skylab Solar Array System (SAS) 

Shown in Figure 24 is the Skylab SAS. The first figure shows the system as it should 
have been deployed. In the middle figure, the destructive liftoff of the auxiliary tunnel as a 
result of the transonic flow induced burst load can be seen. The figure on the right shows the 
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unwrapping of the micrometeoroid shield that was also a thermal shield. While the vehicle was 
not lost, the payload was crippled. However, eventually, a sun shield was added for thermal 
protection and the mission was saved. Saving the Skylab was a complex process that required 
two mission EVA activities [Belew, 1997]. 

This in-flight anomaly was a result of failures in both technical integration and systems 
engineering. All the requirements were not communicated. In reference, [Augustine, 1983], 
there are fifty-two laws (Augustine’s Laws). The forty-fifth law states, “One should expect that 
the expected can be prevented, but the unexpected should have been expected.” 

Space Shuttle Aerodynamics Anomaly 

The first launch of Space Shuttle (STS-1 , Figure 25) produced several surprises. The 
first was the liftoff SRM propulsion induced overpressure problem which yielded the RCS 
system attachment arms and produced large dynamic oscillations of the vehicle. These 
phenomena will not be discussed. The second surprise occurred during ascent when two 
anomalies occurred. First the vehicle lofted significantly more than was predicted indicating 
that there was an unpredicted bias moment acting on the vehicle. The vehicle at SRB 
separation was approximately 10,000 feet higher than predicted. The second anomaly had to 
do with the orbiter wing loads. The trajectory had been designed to fly the vehicle 
conservatively at a predicted 65% of the design limit load; however, the strain gauges showed 
that the wing was experiencing 100% of the design limit load in some areas. The two effects 
were due to the same cause. In designing the vehicle, wind tunnel tests were required to 
develop the vehicle’s aerodynamic characteristics. In order to accomplish an adequate test, 
the propulsion system plumes, including the atmospheric effect on their shape, had to be 
simulated using a solid plume simulator. Analytical techniques available to make the estimate 
of plume characteristics at that time were crude and thus gave an inaccurate answer. The 
plumes, in conjunction with the tunneling effect between the Orbiter wings and the External 
Tank and the Solid Rocket Motors, altered the aerodynamic distribution on the Orbiter wings, 
creating the unpredicted moment and the increased loads on the wings. Initially no one 
believed the strain gauge and aerodynamic pressure data, requiring that all the strain gauges 
be recalibrated. This recalibration showed that the strain gauges on the flight were accurate. 
Many thought that the pressure gauges were recessed too deep causing them to give 
inaccurate data; however after working the problem there was indeed a bias moment on the 
vehicle from the aerodynamic characteristics. 
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Figure 25. Launch of STS-1 

The solution to the problem was complex. If the orbiter wing was beefed up to handle 
the increased loads there would be a 5,000 pound payload loss and a schedule slip of the next 
launch by 2 years. An alternate fix involved flying the vehicle at a -6 degrees angle of attack 
instead of the original -2 degrees, also at a payload penalty of 5,000 pounds. In addition the 
leading edge of the orbiter wing had minor structural beef-up and the External Tank 
protuberances had to be requalified to the new loads. Even with these fixes the original total 
structural capability was not gained, requiring that a Day of Launch 1-Load Update approach be 
added to the operational procedures to bias the trajectory to a wind profile measured 4 hours 
prior to launch, increasing dramatically launch availability. Figure 26 shows the original Q- 
alpha envelope and the reduced envelope that resulted from flying the vehicle in the new way. 
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Figure 26. Space Shuttle STS-1 Aerodynamic Anomaly 

[Ryan, 1996] 

We have discussed the fundamentals of technical integration and two historical space 
system problems as examples of interactions that required unprecedented solutions for the 
projects to continue. In the next section we will go beyond the previous discussion and 
investigate the application of the process to understand Engineering the System with a glimpse 
of the diversity and complexity of the processes a project manager has to manage and make 
the critical decisions about the system. 
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IV. Expanding the Process of Engineering the System 

We now want to go into more depth of the process just described in order to provide a 
better scope of key items a project manager must manage. In general we will use a launch 
vehicle as the example; however, the process applies functionally to each element of the 
transportation system and the total integrated transportation system. The process also can be 
applied generally to other large systems. This section will discuss engineering the total system 
using the following categories: 

A. Process Overview 

B. Requirement Decomposition and Derived Requirements 

C. Subsystem and System Design 

D. Lifecycle Activities Following Detail Design 

E. Decision Making 

F. Managing the Design 

G. The Role of Organizations 

H. Process for Achieving Excellence 

A. Process Overview 

We want to first discuss the underlying philosophy and or approach for the expanded 
process of design. We will then follow it with a look at some of the details of this expanded 
process that is required to understand and manage a space project. The design of aerospace 
systems is an integrated system approach. It is not a Rube Goldberg approach where we just 
throw pieces together and somehow make it perform some unclear function. As represented 
on Figure 27 it is an integrated design approach. 


System Design 



All Design and Discipline Functions must be on the 
design table, in an integrated manner, for each 
phase of the design cycle in order to produce 
quality products 



Integrated Product 


Test Tools 


Figure 27. Lifecycle and Integrated Design Approach 
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As discussed previously, in the past we typically focused our design activities on the 
physical performance of the vehicle, then assessed the design for operability, reliability, and 
cost. What is needed is to design for the total life cycle, which means designing not only for 
performance, but also concurrently designing for the -ilities and cost. We describe this as 
“putting -ilities and costs on the design table”. In order to do this, we need to have functional 
relationships that provide the designer with measures of costs, operability, reliability, 
manufacturability, etc., as a function of the design parameters so that the designer can choose 
a more balanced design. Obtaining the functional relationships needed for the above process 
is a challenge — only a few are currently available. Based on historical or other data, people in 
all technical areas should work to identify functional relationships that connect the -ilities and 
cost to design variables, thus working toward making the -ilities and cost concurrent “design- 
to” attributes along with performance. 

Pugh in his book, “Total Design” [Pugh 1991] deals with this concept of integrated 
design using a cylinder built of integrated sections where information flows from one part to 
another and all the interactions are accounted for. (Figure 28) The model is highly iterative. It is 
life cycle centered, includes programmatic and technical disciplines and encompasses all the 
major activities. The outer shell is driven by the business and customer expectations and 
requirements. The inner core is the life cycle and the basic design. At each major element is a 
circle divided into activities in terms of the order of importance. The block arrows are design 
activities or functions including some of the programmatics. This excerpt is only one of many 
examples that he covers in the book with the emphasis as the title indicates on Total or 
Integrated Design. 
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Understanding Engineering Design 


Technology 


Technique 



Figure 28. The Pugh Engineering Design Model 

[Pugh, 1991] 

This expanded process results in a system that is balanced in the best manner possible 
under the constraints and requirements of the project. Obviously these constraints are not only 
technical but are political, business etc. as well. Figure 29 is an example of some of the trades 
and balancing that are present in the design of a launch vehicle. The chart is taken from the 
Space Launch and Transportation Systems book [Larsen, et. al., 2005] 
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Figure 29. Example Trade Spaces Involved in the Design of a Launch Vehicle [Larson 

et.al., 2005] 

The examples are not the total trade space but provide an illustration of the complexity 
introduced by the number of functions, subsystems, and processes that must be considered, 
traded and balanced. There are many subsets to the areas listed that are also a part of this 
trade space. How we trade and balance these functions, subsystems, elements, and 
components is clearly one factor in producing a successful product. 

The expanded process begins with the mission and general requirements necessary for 
the mission. This set of mission objectives and initial requirements allow us to apply some 
general design understanding of what the system architecture might look like. With this starting 
point the first task is to determine what functions must be performed in order to achieve the 
objectives (Functional Analysis), followed by a list of all the ways that are possible for 
performing each function. Taking this voluminous set of potentials for each function, various 
combinations of these potentials are put together to form different potential architectures for 
the systems. These are evaluated and screened based on criteria that have been determined 
earlier, and the best approaches are selected. Notice that in the formulation of the lifecycle 
functions during both the architectural selection and the concept design and selection phases, 
all aspects of the lifecycle must be a fundamental part of the trade space. However, at these 
early phases of the lifecycle there is less detail in the functions than will exist in the later 
implementation phases. This means that the total system must be balanced during design, 
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iterated some during verification, and occasionally fine-tuned during the operational phase. 
The culture is different during the formulation and design phases than the culture during the 
operational phase as was discussed earlier. Therefore architectures must consider the total 
system and for a launch system, include at least the vehicle, operations, manufacturing, 
verification, and infrastructure. The architecture must now be converted into more detailed set 
of concepts that potentially can satisfy the architecture and the objectives and requirements. 
This is accomplished with a sizing program based on historical characteristics of previous 
launch systems. A small set of the concepts are then carried through a more detailed concept 
design cycle and a final concept selected based on the before-mentioned criteria. Figure 30 is 
a top level look at the process flow. 


Conx^tSeXectCon/ & Sy$te*wV e^ian/ T edwiCccCLl n t&gratvcm/ 

VrocewfloM) 



* Process is the “Technical Integrator" for the above 
steps in the Launch Vehicle design 


Implementation 
Plan/Document 
Plan & Concept 


Figure 30. The Top Level Technical Integration Process for Selection of the Concept 
and the Design of a Space Launch and Transportation System 


Figure 31 provides the basic design objectives of program or project. As this figure 
shows design must not only be concerned with performance but also must design the system 
to preclude failures during the lifecycle or have means of mitigating them. This means that 
during design at any stage of the lifecycle the potential failure modes must be identified and 
addressed. Using these objectives as the focus, the approach for refining the concept design 
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and conducting detailed design of space launch and transportation system is shown on Figure 
32, where the analysis and test portion is commonly called the Design Analysis Cycle (DAC). 

Design Objectives 

System / Subsystems must be 
designed to meet their 


Functional 

Requirements 


H 


Precluding all 



While operating in 


Functional Requirements (Mission Level and 
Derived) come from Life Cycle considerations 
including 

• Performance 

• Reliability 

• Manufacturability 

• Verifiability 

• Operability 

• Cost 

• Schedule 


Natural and 
Induced 
Environments 


At acceptable 


Costand 

Schedule 


Figure 31. The Design Objectives of a Project or Program 
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Figure 32. The Elements of a Space Launch and Transportation System 

Design Cycle 


The program or project manager with support of the chief engineer and the engineering 
department, along with support of any other organizational elements required, are responsible 
for the management of this process. The process starts with the identification/characterization 
of the current concept or configuration and the basic requirements. Starting with this 
information the Design Analysis Cycle (DAC) begins by defining the natural environments 
models to be used in all analysis. Based on the initial configuration and mission profile the 
vehicle aerodynamic characteristics are defined for each mission key timeline. The trajectory is 
redefined using the updated information. The trajectories then become the baseline for 
generating all the rigid body responses and updating the GN&C system. Using the data from 
these various areas all the induced environments (Loads, Thermal, Vibration, etc.) are 
developed at a 3-sigma level. Combining all the information developed the system can now 
define the derived requirements which are added to the base requirements and then flowed 
down from the system. These requirements are now given to all the subsystems to update or 
accomplish the design of each subsystem. Each of the updated subsystems is integrated and 
the system balanced through an iterative process. When completed the new configuration with 
all its accompanying data and characteristics are baselined. 


Figure 33 is an attempt to illustrate the design process in some more detail, but still in a 
simplified form. The difference between this flow and Figure 33 is the block illustrating all the 
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plant (system/subsystem) models and analysis that includes GN&C, loads, thermal, vibration 
and other required analysis. Additional detail is shown for material and manufacturing 
characterization and the internal response/loads typically called stress, safety factors and 
margins added to account for unknowns. In the lower section are the design, manufacturing 
and verification, assembly and operations. Iteration loops are shown to illustrate the constant 
need to balance the total system. 



Figure 33. A Simplified Flow Diagram of the Design Process 


The functions of the activities that lead to the design specifications are: 

• Identifies all potential failure modes of the system and subsystems. 

• Conducts the analysis, test, simulation, using uncertainties, sensitivities, interactions, 
margins, risks and trades to arrive at the derived requirements for the system and 
subsystem design that includes the launch vehicle, manufacturing, operations, -ilities 
etc. 

• These requirements not only include the subsystem design requirements but also the 
best way to fly the vehicle in the best balanced state. 

• Project managers are responsible for managing this effort in a way that makes the 
process efficient, and does not become overly conservative. 
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The functions of areas captured in the design, manufacturing and operational blocks and the 
reintegration of the system are: 

• Using the derived requirements and how we fly the vehicle, the system and subsystem 
is designed, built, verified and operated. 

• The system is balanced using trade studies based on uncertainties, sensitivities, risks 
and margins along with cost and schedule. 

• Project managers are responsible for ensuring that the system is balanced, safe, 
reliable, and has adequate margins and flexibility. 

B. Requirements Decomposition and Derived Requirements 

The selected concept becomes the baseline for the design process which is started by 
decomposing the requirements into lower level requirements. This is a very iterative process 
and results in more and more in-depth lower level requirements typically called derived 
requirements. 

The decomposition of requirements to lower level can become very intensive and 
detailed. For example, decomposing the requirement that the system have attitude control for 
path deviations and that it must be stable can take the following top-level form: 

• Navigation system avionics 

• Sensors and sensor location 

• Thermal conditioning 

• Shock and vibration isolation 

• Software 

• Flight computer 

• Software for control system algorithms 

• Processing cycle time implementation 

• Thrust vector control system for attitude control forces that leads to requirements 
for 

• Gimbal throw angle 

• Gimbal rates 

• Gimbal accelerations 

• Gimbal system uncertainties 

• Response amplitude and phase as function of frequency 

• Structural constraints 

• Stiffness/frequencies 

• Load paths/attachments 

• Slosh baffles 

• Resulting manufacturing, verification and operation requirements 

These top-level requirements are decomposed and expanded as the design process 
matures. As the subsystem’s design evolves, it must be reintegrated back into the system and 
the system effects determined. This can result in a change in its design or a change in the 
derived requirements including additional requirements. 
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Managing the development of the derived requirements is crucial to the success of the 
project. The derived requirements usually are many of the drivers to the system design and 
operations. Management of this activity is very detailed and time consuming, with the 
derivation of the derived requirements utilizing large manpower and computer resources. At 
least the following two areas are involved in the process. 

• Natural Environments 

• Induced Environments 

1. Natural Environments 

The natural environments are the environments which exist whether a space system is 
present or not. They are the environments that exist due to the natural state of our universe. 
They include atmospheric density, temperature, winds, solar pressure, magnetic fields, etc. A 
more detailed list is shown on Figure 34 for the terrestrial and space environments. Figure 35 
shows examples of the atmospheric winds, temperatures, and density. These environments 
are a statistical measure over time at the various launch sites at different points in space. Each 
has to be modeled to be compatible to the mission event being analyzed. Ensuring this 
compatibility is one of the integration tasks the project manager and chief engineer must 
perform. 


• Terrestrial Environments: 

o Winds, Turbulence o 

o UV & IR Radiation o 

o Flora & Fauna o 

o Atmospheric Electricity o 
o Sea States o 

o Geological Hazards 


• Space Environments: 

o Near-Earth Thermal o 

o Meteoroids o 

o Orbital Debris o 

o Magnetic Fields o 


Atmospheric Thermodynamic Properties 
Precipitation, Fog and Icing 
Cloud Characteristics & Cloud Cover 
Tornadoes, Hurricanes & Severe Weather 
Atmospheric Constituents 


Atmospheric Constituents (Atomic Oxygen) 
Solar Activity & Atmospheric Density 
Ionizing Radiation 
Plasma/Spacecraft Charging 



Figure 34. List of Typical Natural Environments Necessary to be Defined for Space 

Systems Design and Operations 

[SLaTS Course - Natural Environments, 2010] 
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Natural Environment Examples 


KSC February Vector Wind Profiles 


KSC U-Wind 
Component (m/s) 
99% probability 
ellipse profiles 0-27 
km for reference 
alt = 12km. 



KSC V-Wind 
Component (m/s) 
99% probability 
ellipse profiles 0-27 
km for reference 
alt= 12km. 





GRMd Profiles of Density Perturb alion 


f“ 

!» 




Figure 35. Atmospheric Winds, Density and Temperature Examples 

[SLaTS Course - Natural Environments, 2010] 


2. Induced Environments 

Induced environments are environments caused by the launch vehicle, spacecraft or 
other elements and their operations, producing interactions within their own systems and with 
the natural environments. How well we manage the derivation of the induced environments 
and the resulting derived requirements have major impacts on the space system being 
designed. It is a very critical area for management to ensure adequacy without undue 
conservatism. The resulting induced environments that typically drive the derived 
requirements include: (Only those in italics will be discussed as examples) 

1) Aerodynamics 

2) Trajectory responses 

3) Control responses 

4) Vehicle loads 

5) Induced thermal environments 

6) Vibroacoustics 

7) Electromagnetic interference 

8) Radiated RF energy 

9) Pyrotechnic shock 

10) Vehicle-generated debris 

1 1 ) Effluent from propulsion systems, separation motors, other systems 

12) etc. 
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T rajectory Responses 

Trajectory design integrates and balances the launch vehicle system between the 
various subsystems and design functions, determining the best path to fly to the target. It also 
determines whether the vehicle design supports the capability to reach the target and anchors 
flight operations. Designing an ascent trajectory is complex because of the changing 
environments, from atmosphere to exo-atmosphere, and the variety of optimizing parameters 
and constraints. To design a good ascent trajectory, we must include liftoff, pitch-over, flight 
through maximum dynamic pressure, staging conditions, and flight in the vacuum of outer 
space. Optimizing the trajectory requires that we understand and balance among the highly 
variable characteristics of each event of the trajectory. The atmosphere, vehicle motion, forces, 
and vehicle mass all vary rapidly as the ascent trajectory progresses. As a result, constraints 
such as clearing a launch tower, minimizing structural loads, and limiting acceleration affect 
different parts of the trajectory, as do abort requirements. The trajectory parameters are 
optimized in different ways over various flight phases. For example, the initial pitch-over angle 
and the vacuum flight path are optimized for maximum payload delivery, while the liftoff and 
flight through the region of high dynamic pressure are more constrained. The liftoff trajectory is 
constrained by tower clearance requirements. The predominant factor in the high dynamic 
pressure region is usually vehicle loads, which are a function of the dynamic pressure and the 
wind effects. We have many trades and optimization parameters available for designing the 
flight trajectory. We consider each event and then integrate the total trajectory, which means 
we must balance the system among the conflicting requirements of each. Figure 36 is a flow 
diagram of the trajectory design process showing many of the inputs and outputs of the 
process. The trade studies shown in the small box are key to achieving an adequate product. 
Examples of these trade studies are listed in the following paragraph. 



Figure 36. Typical Trajectory Design Inputs, Outputs and Trade Studies Flow 

[SLaTS Course -Trajectories, 2010] 
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Trajectory Design Trade Space 

• Wind biasing: Impacts structures, vehicle control, and launch availability. 

• Aborts: Examination of abort trajectory possibilities and alternate landing sites. The 
abort trajectories can drive some aspects of vehicle design. 

• Mission orbit: A different target orbit impacts the payload performance, the sizes of 
stages, and thermal/structural/etc. disciplines due to use of a different trajectory. 

• Performance to final orbit: Mix of launch vehicle and upper stage, delta V split 

• Vehicle partials: The impact on payload, vehicle constraints, and landing success from 
a change in each important trajectory design parameter 

• Launch site choice: Trades on performance, launch window variation with launch site, 
stage impact areas 

• Launch window analysis: Launch window payload penalty; how often does the launch 
window recur? 

• Rendezvous: How many days between launch opportunities? 

Figure 37 represents a typical launch vehicle trajectory for a vehicle with a flyback 
booster. Major events of the trajectory as pointed out on the figure include liftoff, optimized 
pitch over, maximum dynamic pressure, pitch/yaw optimization, staging, and orbit insertion. 



Figure 37. Typical Ascent Trajectory 

[SLaTS Course -Trajectories, 2010] 
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Control System Design and Responses 

Once a baseline trajectory is determined along with the rigid body aerodynamic 
characteristics, we can accomplish a control system initial design and determine its 3-sigma 
responses to system parameter uncertainties and natural environments. These responses 
become inputs to the thermal and loads community for calculating associated induced 
environments. Figure 38 illustrates the initial control design/response process. Figure 39 is a 
typical control response calculation process. The lower left hand portion of the figure is the 
output of a Monte Carlo analysis of the various parameter uncertainties and winds where each 
circle represents an individual run. The plot is for q-alpha and q-beta at a given Mach number, 
which are indicators of aerodynamic load on the vehicle. Plotting an envelope around the 
individual runs for each Mach number and combining the results produces the squatcheloid 
shown on the lower right side of the figure. This squatcheloid is an envelope, usually at the 3- 
sigma level, of the q-alpha and q-beta combinations on the pitch and yaw planes of the launch 
vehicle trajectory plotted versus Mach number. The results of the control system design and 
response analysis, along with the previous data discussed, become the inputs that are used by 
the loads and thermal analysts to derive their respective induced environments. 


1. Based on configuration, establish control gains and 

and control frequency. (Chapter 10.2) 

- Set gains to provide adequate response 
without incurring flexible mode stability problems. 

- Set gains to obtain desired balance of attitude response, drift response, and 
load relief. 

-In simulation, include details appropriate to design maturity, 
e.g., flexible modes and filters 

2. Develop control responses with wind disturbances and parameter 
variations to determine induced environments. 



Figure 38. Control System Initial Design and 3 Sigma Response Calculations 

[SLaTS Course -Control, 2010] 
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Response - Design Conditions for Loads 



Winds 



Control Simulation 

Monte Carlo 



Parameter 

Variations 



Qa Qp Load Indicators 


Squatcheloid Set 




To 

Loads 


Figure 39. Typical 3-Sigma Control Responses for Induced Environments 

Determination 

[SLaTS Course - Control, 2010] 


Loads 

Using the data generated by the analyses shown above, external loads are calculated 
for each mission event. These calculations usually require different models for analysis of each 
event and must include any additional parameter uncertainties not considered in the previous 
analysis. Figure 40 is a typical example of major sources of loads for a launch vehicle and 
Figure 41 is a flow diagram of the basic process for loads determination. 
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Major Sources of Aero-Mechanical Loads X 





Maneuvering 

Thrust Oscillations (typically below 30 Hz) 


Figure 40. Basic Load Sources for a Launch Vehicle 

[SLaTS Course - Loads, 2010] 


Loads Analysis Process 


Process 


Inputs 


System 


Aerodynamics 


Natural Envim 


Trajectory 


Control 


Propulsion 


Materials 


Operations 


Analysis 


Rigid Body 

- Rigid body dynamic response 

— Inertia effects — Control forces 
— Aero 

Elastic Body 

- Mode shapes and natural frequencies 

- Slosh masses and slosh frequencies 

- Dynamic response: 

-- Ground Winds -- Lift-off 

-- Overpressure — Wind gust 

— Buffet — Docking 

— Thrust Oscillation — Maneuvering 

- Static elastic effects 

Uncertainty 

-Aero distribution 

- Inertial 

- Control 

- Natural environment 

- Trajectory parameters 


Outputs 


3o Aero-Mechanical 3o Composite Design 

Loads Combination Loads Combination 



Figure 41. Basic Loads Analysis Process for a Launch Vehicle 

[SLaTS Course - Loads, 2010] 








Examples of major loads design considerations for various flight events are: 

• Rollout 

- Crawler speed 

- Wind criteria 

• Prelaunch 

- Stay damping & stiffness / active control 

• Liftoff 

- Wind criteria 

- Stay & damper soft release 

• Ascent - First Stage Flight (FSF) 

- STEL (Static Elastic) 

• In-Flight Load Relief - IFLR 

• Day-of-Launch - DOL 

• STEL dispersions in Loads Combination Equation (LCE) 

• Wind persistence - more balloon launches 

- Gust 

• Turbulence model 

- Buffet 

• “Borrow” capability from STEL 

- Maneuvering 

• Steering changes 

• Staging 

- Transients 

- Booster tumble motor firing 

• Ascent - Second Stage Flight (SSF) 

- Ignition sequence timing 

- Ignition gimbaling 

- Tighter CG control 

All the various load events analysis results are presented as shear, moments and then 
combined into what is normally called P-equivalent or running loads. Figure 42 is a typical P- 
equivalent load plotted versus the launch vehicle length. Since the external loads are one of 
the major drivers on vehicle weight and many of the operational procedures, it is mandatory 
that the project managers understand and carefully manage these activities. Here again we 
are dealing with some of the major integration activities and how the total system is balanced. 
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Overall Combined Envelope Comparison 



Figure 42. P-equivalent Load for a Typical Launch Vehicle 

[SLaTS Course - Loads, 2010] 


Thermal Environments 

The next main driver for induced environments is thermal. Thermal environments have 
their source in aero heating, plume heating, power systems, human presence etc. as shown on 
Figure 43. Typical thermal environments encountered by Shuttle during ascent flight are shown 
on Figure 44. Determination of the thermal environments requires many inputs as illustrated on 
the left hand side of Figure 45. The systems integration job dictated by this large number of 
interfaces for inputs and the corresponding outputs to various design groups is complex and a 
challenge to managers. The thermal environments impact many design and operational 
requirements and are a major driver on the system and subsystem design and operations. 
Again as in loads different models have to be developed and analyzed for each of the major 
mission events. Numerous and complex tests are required to verify the environments and are 
a part of the validation and certification a system for flight. 
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Thermal Environments by Mission Phase 



Ground 

Processing 

Environment 


Pad Environment with 
Propellants Loaded 


a 

Ascent 

Flight 

Environment 



Space 
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Earth 

Entry 
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Post 

Landing 

Environment 



Transportation 

Environments 


Figure 43. Typical Sources for Thermal Environments 

[SLaTS Course - Thermal Environments, 2010] 



Figure 44. Typical Thermal Environments Encountered by Shuttle During Ascent [SLaTS 

Course -Thermal Environments, 2010] 
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Inputs 


Outputs 


• Atmosphere as a function of altitude 

■ Density 

■ Temperature 

■ Viscosity 

• Trajectory versus Ascent Flight Time 

■ Altitude 

■ Velocity and Angle of Attack 

• Vehicle Geometry 

■ Vehicle Dimensions 

■ Aerodynamic Shapes 

■ Compartment Configurations 

■ Base Configuration 

■ Number and Size of Engines 

• Propellants (temperature and pressure) 

■ Rocket Engine Performance Characteristics 

■ Engine Chamber Pressure & Mixture Ratio 

■ Nozzle Area Ratio 

■ Thrust 

• Natural Environments 

■ Ground Processing 

■ Pre and Post Launch Operations 

■ Post Landing Operations 

• Vehicle Aerodynamics 

■ Inviscid Flow Field 

■ Local Pressures & Temperatures with Flight Time 


• Aerodynamic Heating 

■ Recovery Temperature or enthalpy 

■ Heat Transfer Coefficients 

• Base Heating 

■ Plume Characteristics 

■ Convective Base Gas Temperature 

■ Heat Transfer Coefficients 

■ Plume Thermal Radiation 

• Protuberance Heating 

• Heating due to Flow Separation 

• Vehicle & Plume Flow Field Interaction 

• Compartment Environments 

■ Ingestion of Gases 

■ Venting Characteristics 

■ Cryogenic effects 

• Ground and Pad Environment 

■ Vehicle Processing 

■ Pre Launch Design Considerations 

• Entry Environments 

■ Recovery enthalpy 

■ Heat transfer coefficients 

• Post Landing Environments 

■ Heat Generated & Stored During Entry 

■ Landing and Post Flight Processing 


A A 




Thermal 

Environment 

Definition 


Detailed design and performance data are required for environment definition. 
Environments are quantified for all mission phases and vehicle systems. 


Figure 45. Inputs and Outputs of the Thermal Environments Determination 

[SLaTS Course - Thermal Environments, 2010] 

We have discussed only some of the induced environments as examples of the project 
manager’s task of determining the induced environments. Once these tasks have been 
performed for all the induced environments they are combined together to form the formal set 
of derived requirements, 

3. Derived Requirements Summary 

Combining together all the induced environments and the other requirements that result 
from balancing the system provides the basis for determining a formal set of derived 
requirements. These requirements are then levied on the system to design or modify the 
design of the system, the subsystems, and components. Figure 46 is a partial listing of 
categories of some of these requirements by subsystems. This is a very complicated and 
formal process that requires detailed attention by management as well as by all the practicing 
disciplines. These requirements become the drivers for the design and for operations of the 
project. 


59 






- Propulsion 

--Thrust, l sp , Propellants, Weight, Size, MR, Throttle, TVC, 

Gimbal, No. Engines, Natural and Induced Environments, Interfaces, etc. 

- Avionics 

-- Natural and Induced Environments, Interfaces. 

- Electrical Power. Power Profile, Fault tolerance, Redundancy, 
and Reliability. 

- RF Communication: Data Transfer, Time Space Position Information/Tracking, 

Range Safety, Flight Termination, Voice, Video, etc. 

-- Electro Magnetic Environmental Effects: Protect Against - Radiated Emissions, 

Radiated Susceptibility, Conducted Emissions, Conducted Susceptibility. 

-- Command an Data Handling : Sensor Processing, Algorithm Hosting, Avionics 
System/Architecture, Measurement and Command Lists, etc. 

-- Sensors and Instrumentation: Type, Sensitivity, Stability, Selectivity, Accuracy 
Repeatability, Easy to Fabricate, Min Hardware requirements, Reversible, and 
Fast Response Time. 

-- Range Safety System: AFSPMAN91-710, Security, Reliability, Trajectory, 

External Shape, Control System layout and Authority, Propellant types. 

- Software: 

--Mission and Project Requirements: Spacecraft, Instruments, Operations, Performance, 
Schedule, Funding 

- Mission Systems Engineering: Flight Hardware Redundancies, Onboard Autonomy, Onboard 

Failure Handling Philosophy, Vehicle System and Fault Management 

-- Guidance, Navigation & Control: GN&C Hardware Decisions, Specs. & ICDs, Control Modes, 
Control Algorithms, Control Options 

-- Science Instruments: Data Rates, Interfaces to s/c, Data Handling, Data Processing, Algorithms, 
Event Handling 

-- Science & Mission Operations Data Flows, Planning/Scheduling, Ground Contact Strategies 

-- Electrical Subsystems Flight Data System Architecture Specs, and ICDs (RF, CPUs, memory, 
buses, datastorage, power) 

-- FSW Test, Maintenance & Remote Troubleshooting Strategies: Diagnostics, Flight Database, 
Loads, Dumps 

-- Special Hardware/Software l&T Requirements: Direct ground\crew commanding of flight 
hardware 

-Pre-launch and Launch Requirements: Launch-unique Configurations, Launch Vehicle 
Separation, In-orbit Sun Acquisition 


- Structures 

-Architecture, Size, Propellants, Weight, Materials, 
Manufacturing, Operability, Sensors, 
Subcomponents, Secondary Structures, Natural 
and Induced Environments, Engine Mountings, 
Interfaces, etc. 

- GN&C 

- Natural Environment 

-Vehicle Configuration and Structural 

- Performance and Trajectories 

- Aerodynamics 

- Structural Analysis 

- Propulsion 

- Thermal 

- Avionics and Electrical Power 

- Mechanical Systems 

- Thermal 
-Thermal Environment 

- Natural and Induced Environments 

- Structural System 

- Propellant System 

- Pressurization System 

- Engine Systems 

- Propellant Transfer Systems 

- Avionics Subsystems 

- Payload Accommodations 

- All Systems and Subsystems 

— Ilities; Reliability, Maintainability, Safety 
Operability, Quality, ... 

- Cost 


Figure 46. Example Categories of Refined Derived Requirements for 

Subsystems/System 


C. Subsystem and System Design 

1. Subsystem Design 

Figure 47 is a flow diagram for the process that the subsystems employ to impact the 
design as a result of the flow down of the derived requirements. Notice that there is balancing 
of the system and the determination of additional requirements which are then flowed back to 
the system. Shown on Figure 48 are typical subsystem design areas. Illustrated are only the 
Propulsion, GN&C, Structures, Thermal, Avionics, and Life Support subsystems. Others are 
added as dictated by the characteristics of the project. Management of the activity is critical to 
the success of the program and or project. Figure 49 is a pictorial of these subsystems for a 
typical launch vehicle. Other space systems such as spacecraft would have a similar list. 
These areas will be addressed in more detail in the following sections. 
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Design and refine subsystems 

Identify requirements on other subsystems and system 
Determine subsystem attributes including sensitivities 



Figure 47. Application of Derived Requirements to Subsystem Design 
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Figure 48. Typical Subsystems that Require Design Activities in the Process 
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Figure 49. Typical Subsystems of a Launch Vehicle - Ares I Example 


2. Example Subsystems 

Several of the subsystems will be discussed in more detail in the following sections 
including their characteristics, options or trade areas, and the reintegration activities that are 
required to balance the system in the most efficient manner. The following subsystems will be 
briefly discussed: 

a) Guidance, Navigation, and Control (GN&C) 

b) Propulsion Systems 

c) Structures 

d) Thermal 

e) Avionics 


a. Guidance, Navigation, and Control (GN&C) 

The GN&C system guides the vehicle from launch to the desired orbit insertion in a 
stable manner while maximizing payload mass delivered, subject to constraints on structural 


62 




and thermal loads. The navigation system continually estimates, based on suites of sensors 
and Kalman filters, the position and attitude of the vehicle. Based on the estimation of the 
navigation system, the guidance system continually reprograms the guidance path to the most 
efficient direction to the target in space. The control system uses this path angle command to 
keep the vehicle oriented along the guidance path while maintaining acceptable dynamic 
response to disturbances. The control system is also responsible for maintaining the vehicle 
stability for rigid body responses, elastic body responses, propellant sloshing and 
aeroelasticity. Additional functions can be added such as wind biasing and load relief control 
to reduce weight or increase launch availability. These activities become additional parts of the 
balancing the system that must be considered. 

Figure 50 illustrates the basic elements of the control system, including sensors (inertial 
measurement units, rate gyros, accelerometers); software in the flight computers containing 
navigation filters, guidance programs, control laws with appropriate gains and filters; and 
control effectors for control forces. Control effectors include thrust vectoring systems (typically 
actuators and hydraulic power units) and reaction control thrusters. Selecting or designing the 
control system hardware and software/computer provisions is an interactive activity with the 
control law / dynamic response design. 

Basic Control System Elements 



Figure 50. Control Functions and Elements for Implementing the Functions 

[SLaTS Course - Control, 2010] 
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b. Propulsion 


The first function of propulsion systems is to provide the energy required to propel the 
system in space. For a launch vehicle this is a very high performance and concentrated power 
density system that is very complex and fraught with high sensitivities and many unwanted 
interactions. Normally the main propulsion can be separated into liquid and solid systems, with 
further categorizations of these two basic systems into various implementation options. 
Auxiliary propulsion systems used for vehicle control and other functions are separate and 
challenging additional systems. Figure 51 is an example of a liquid main propulsion system 
showing its functions and subsystems along with some of the design issues that drive the 
system. 


Main Propulsion System (MPS) Design Issues 


Safely & efficiently provide 
propellant & any associated fluid 
needs to the engine 

Safety 

• Provide uniform & stable flow to engine 
. . . avoid or sense & react to propellant 
depletion 

• Provide safe & efficient system for 
fill/drain (isolation, sequence, 
conditioning) 

• Propellant leaks (fire / explosion) . . . 
joints, seals, purges, propellant vent / 
relief & drains 

• Cleanliness (remove moisture, foreign 
object / debris, propellant quality) . . . 
purges, vents/drains, & filters 

• Avoid flow disturbances & instabilities . . . 
such as “pogo” (coupling of engine & 
vehicle system) & cavitation (localized 
vaporization) 

• Fire/explosion and material compatibility 
. . . thermal (heating, freezing, 
liquefaction, reduced viscosity), corrosion, 
air (0 2 ) intrusion 

• Thermal issues (heating, freezing, 
liquefaction, reduced viscosity, “thermal 
shock”) for operation and added h/w life 




Pressurization 



(Valve Control & 
Purge) 


Performance 

•Propellant temperature & pressure 
(density, enthalpy, quality) 

•Energy/thermal mgmt (insulation & 
conditioning to keep cold things cold, hot 
things hot) 

• Minim ize propellant boil-off (loss) 

•Maintain pressure (minimize losses) . . . 
engine performance & structural stability 
of large surface area tanks 

• Accurate loading & consumption 
accounting of propellants, all fluids 
(minimize mass) 

Fluid Control 

Propellant 
•To/from engine(s) 

•Fill/drain to/from ground supply 
Pneumatics 

•Operate pneumatic valves 

•Purges . . . clean, remove moisture, dilute 
or separate incompatible materials or 
combustible mixtures 

•Pressurization (propellant tanks) 

• Either from tanks (organge) 

• Or from engine (dotted lines) 


Figure 51. Liquid Main Propulsion System Functions and Design Drivers 

[SLaTS Course - Propulsion, 2010] 

The classic example for efficiency of liquid propellant systems is the SSME. As noted 
earlier, a turbine blade that is about the size of a human thumb generates 550 horsepower and 
operates at a temperature of 1800 degrees Rankine. The high pressure fuel turbopump is 
about 2 feet long and 18 inches in diameter. It spins at 30,000 RPM and generates 70,000 
horsepower. The turbine end of the pump is at 2,000 degrees Rankine while the other end that 
pumps liquid hydrogen runs at -422 degrees. Development of the SSME incurred 38 major 
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failures during testing that were very costly in material, hardware, facilities and schedule. 
Several redesign cycles or block changes were made to eliminate many of the interaction 
problems that occurred during development. Managing these complex systems requires the 
best available systems engineering and technical integration processes and techniques. The 
following is a list of some trades and considerations for the design of liquid propulsion systems: 

1 . Engine cycle 

2. Propellants 

3. Thrust level vs. number of engines 

4. Thrust to weight 

5. Isp vs. tank size 

6. Materials and manufacturing options 

7. Verification/certification 

Figure 52 is a cross section view of a solid rocket motor propulsion system. Illustrated is 
how the internal grain pattern is shaped to create variations of thrust versus burn time. Other 
solid propulsion design issues involve aspect ratio, grain properties, insulation, nozzle thermal 
protection, igniter design, thrust vectoring, case materials, and manufacturing processes. 

Solid Rocket Motor Components: 

Propellant Grain 



+ The propellant grain is the precisely shaped mass of cured solid propellant 

+ The grain can be designed with a wide variety of cross-sectional shapes and 
end-to-end tapers designed to give a precise thrust profile with time 




Center perforation Slots & tube 
(progressive burn) (neutral burn) 



Wagon wheel Dendrite 
(neutral burn) (neutral burn) 



Dog bone 
(neutral burn) 



Multi perforated 


(neutral burn) 


Figure 52. Solid Rocket Motor Components and Various Grain Patterns to 
Produce Precise Thrust Profiles with Time 

[SLaTS Course - Propulsion, 2010] 
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Auxiliary propulsion systems are used to perform basic control functions when main 
propulsion systems or aerodynamic control force systems are not available, to provide orbit 
maneuvering and maintenance functions, and to aid in separation and propellant settling 
functions. They are the systems used on many orbiting space systems. Figure 53 shows the 
standard functions and functional implementation of these auxiliary propulsion systems. The 
table lists the functions, why needed, and typical examples of current implementations. 

Common Types of Launch Vehicle Auxiliary Propulsion 


Function When Needed Why Needed Familiar Examples 


Roll Control 

• When single engine 
or motor provides 
main thrust (since no 
opposing engine can 
be used to provide 
roll) 

• Antenna 
orientation 

• Astronaut horizon 
orientation, 
visibility 

• A 

^res I First Stage Roll Control System 

Reaction 

Control 

• When earth-to-orbit 
vehicle must place 
payload into orbit 

• When earth-to-orbit 
vehicle is staged 

• Propellant settling 
for upper stage 
engine restart 

• Assist with stage 
separation 

• s 

F 

latum S-IVB Upper Stage Auxiliary 
hopulsion Systepi 

• When vehicle 
provides orbital 
maneuvering 
capabilities 

• When vehicle 
provides controlled 
deorbit or re-entry 

• Stationkeeping 

• Orbit adjust 

• Proximity 

op erations, docking 

• Unload momentum 
wheels, if present 

• Re-entry control 

• s 

F 

Ihuttle Orbital Maneuvering System and 
Leaction Control System (OMS/RCS) 


Figure 53. Common Types of Auxiliary Propulsion Systems 

[SLaTS Course - Propulsion, 2010] 

The propulsion community has established a comprehensive lessons learned data base 
that is available for designing future systems. Figure 54 is one example of a summary chart of 
the history of some of the problems and corrective actions experienced by the Space Shuttle 
Main Engine (SSME). This data base includes most of the corrective actions required during 
the development program of the SSME. Also available are all the SSME major development 
failure reports. The design and operation of systems such as SSME are very challenging and 
are as complex as the design and operation of overall space systems such as a launch 
vehicle. The efficiency of the propulsion system in conjunction with the structural system are 
the major drivers in balancing the design of a launch vehicle. 
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SSME Problem History / Lessons Learned 


• Development process intended to catch and eliminate problems that will 
compromise ability to meet requirements 

• Lessons learned from prior programs are invaluable in pointing design 
team toward areas needing emphasis 



Figure 54. Lessons Learned in Liquid Propulsion Systems / Space Shuttle Main Engine 

[SLaTS Course - Propulsion, 2010] 


c. Structures 

The mass efficiency of structures is a key consideration in the design of launch vehicles 
and spacecraft. One term that is used for efficiency is mass fraction. Propellant mass fraction 
is the ratio of the propellant mass to the total loaded mass of the system. Mass fractions of 
launch vehicle stages typically range from about 0.85 to 0.90. 

There are many trades and considerations that have to be conducted and decisions 
made in structural design. The following is a typical list. 

1 . Expendable vs. reusable 

2. Inline vs. parallel 

3. Propellant tank location and configuration 

4. Load paths - load lines 

5. Thrust structure: Shell vs. space frames 


67 



6. Bulkheads: common vs. separate, dome shape 

7. Isogrid vs ring frame and stringers, honeycomb, monocoque, 

8. Material: metallic vs. composite 

9. Welded, bonded, mechanical fasteners 

10. Spin formed, break formed, roll formed, age formed, machined, layup 

Figures 55-57 illustrate a sample of some of the considerations and trades in structural 
design. The results of these trades affect not just the structures subsystem but also the total 
system. Therefore, to be correct, the structural trade decisions must be made from a total 
system viewpoint. 




Delta IV Heavy 
Stage 

• 2219 isogrid tank 
construction 
• L02 tank not in 
primary load path 


- Centaur Upper Stage 

• Pressure stabilized 

• Welded stainless steel 
construction 

• Common Bulkhead 

- Insulated on interiorof LH2 
tank 


- Ariane 5 ESC-A 
Cryogenic Upper 
Stage 

• L02 tank not in 
primary load path 


Figure 55. Examples of Structural Design Trades and Concept Selection Options 

[SLaTS Course - Structures, 2010] 
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Stiffener Concepts (Built-Up Shells) 


• Wall Construction 


- Unless structure is pressure 
stabilized or Composite, 
stiffeners are generally 
required to prevent buckling 

- Stiffeners may be machined 
into parent material, bonded, 
welded, or mechanically 
attached 
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Mechanical attachment can 
be costly and is generally 
limited to unpressurized 
structures 
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Tank Wall Integral Stiffener Concepts 


• Machined ribs with flanges 
can be difficult to inspect 
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Figure 56. Examples of Structural Design Trades 

[SLaTS Course - Structures, 2010] 


• Load path 

- Care must be used in spreading concentrated point loads 

• Design so re-enforcement thickness spreads the load (shear lag) 

• Best to end re-enforcement of eccentric loads at a structural ring to 
reduce radial loading into the skin 

• Examples: SRB attachment points 
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• Load path and stiffness 

- Loads go to stiffer paths in the direction of loading 

• Load will be a ratio of the stiffness 

- Increasing thickness of weld lands can draw 
load 

• Holes and gaps are areas of no stiffness which 
result in higher stresses at the edges/corners 
that need re-enforcement 

- Access Doors 

- Gaps in separation rings 

• Consider impacts of stiffness across component 
joints between tanks and skirts 

• Repairs or reinforcements should not be made 
overly stiff 
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Figure 57. Load Path Considerations in Structural Design 

[SLaTS Course - Structures, 2010] 


d. Thermal Systems 

Thermal systems have many functions, for example: maintaining propellant condition, 
keeping materials temperature within its capability limits, maintaining human environments, 
equipment environments, etc. Figure 58 is a block diagram of the basic thermal design 
process. It starts with requirements, followed by determination of induced environments, the 
identification of design and material options, trade studies, design and verification. Figure 59 is 
a checklist to help in managing the process. Figure 60 provides some typical examples of the 
heating and thermal protection and control systems. 
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Process Steps: Thermal Protection and Control Systems 


Define key requirements and 
design drivers 

• Identify thermal design 
requirements with regard to 
mission, reusability, vehicle 
configuration, and subsystems. 


Determine natural and induced 
environments 

• Determine environments for 
prelaunch, ascent, orbital 
operations, entry, and post 
landing. 


Identify design options and 
material systems 

• Consider design options 
including heat sinks, insulated 
structures, and active and 
passive control systems. 

• Identify candidate material 
systems. 


Accomplish trade studies 
and select a configuration 

• Make trades for vehicle 
thermal protection and 
control systems to 
determine desirable 
design solutions. 

• Select the configuration 
and material systems for 
design evaluation. 


Design analyses and sensitivity studies 

• Analyze configurations for thermal protection and 
insulation systems. 

• Define power and interfaces required for thermal 
control systems. 

• Provide thermal response for structural design 
consideration. 

• Provide weight, power, and volume estimates. 

• Assess the selected configuration for margins and 
sensitivities to variations in environments, material 
properties, and manufacturing limits. 


Define development 
and verification plan 

• Define development, 
acceptance, 
verification, and flight 
testing approach. 

• Identify facility 
(manufacturing, test, 
and assembly) 
requirements. 


Several cycles through the process are usually required. We need iterations to find the best launch 
system solution. Uncertainties will diminish as the development program matures. 


Figure 58. Thermal Protection and Control Systems Design Process 

[SLaTS Course - Thermal Systems, 2010] 
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System/Environment 

Consideration 

Historical Deiivation/Sourcc of Requirement 

Propellant system 

Control temperature and pressure 
Determine operational timeline 

Cryogenic conditions, maintain structural limits 
Facility propellant transfer and vehicle conditioning 

Pressurization system 

Control temperature and pressure 
Determine operational timeline 

Thermodynamic stale, maintain tanks within limits 
Pressurization flowrate, pressure, and temperature 

Ascent aerodynamics 

Evaluate pressure & temperature 
Assess altitude and velocity 
Design for acoustics and vibration 

Trajectory design 
Trajectory design 
Induced environment 

Structures and interfaces 

Evaluate pressure & temperature 
Determine loads. Predict strain 

Structures & materials allowable temperature 
Structural design analyas, Design loads prediction 

Terrestrial environment 

Evaluate temperature, humidity, precipitation 
Evaluate wind (ground and flight) 
Atmospheric pressure/density 

Natural environment at launch site 
Standard atmosphere 
Standard Atmosphere 

Space environment 

Evaluate thermal radiation, micrometeoroid and 
orbital debris environment, and molecular heating 

Natural and Space environment. Debris hazard 

Entry environment 

Evaluate pressure & temperature 
Assess altitude and velocity 
Design for acoustics and vibration 

Trajectory design 
Trajectory design 
Induced environment prediction 

Engine systems and components 

Determine internal environments 
Assess pressure and temperature 
Define fluid const ituents/species 
Evaluate thermal radiation 

Propulaon system design 

Propulsion system design 

Propellant and combustion product species 

Propulaon system design 

Avionic & payload accommodation 

Control temperature & accommodate heal loads 

Condition electronics & provide service to payloads 


During conceptdefinition, we should analyze the systems and environments shown forsensitivity to 

expected operating conditions. 


Figure 59. Launch Vehicle Thermal Design Checklist 

[SLaTS Course -Thermal Systems, 2010] 
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Heating Phenomena 


Stagnation Point 
Conditions\ 

Free Stream 
• Pressure 
•Temperature 
•Mach Number — > 

•Density Subsonjc 

•Viscosity Region 

Supersonic 
Region 


I Flow Field 

Turbulent Boundary Layer 



a 



Bow Shock 


Vehicle Boundary Layer 

Flow Reversal (high altitude) 


Payload Fairing and Aeroshell 
Structures Requires Thermal 
Protection 




1 


Pay bad Accommodations 
include Environmental and 
Thermal Control 


Thermal Protection and Control 




Aft Compartment, Inter-stage and Inter- 
tank Volumes Require Environmental, 
Thermal, and Hazard Control 

/ _ t \ 


Engine /Motor Subsystems 
and Components Require 
Thermal Design and Thermal 
Conditioning 


Avionics Housed in 
Compartments Require 
Thermal Control 


Base HeatShield and 
Nozzle Require Thermal 
Protection 


PropellantTanks Require Cryogenic Insulation, Propellants 
and Pressurization Systems Require Thermal Conditioning 


Virtually all areas of the vehicle are exposed to temperature extremes and heating or cooling. Thermal 
protection , cryogenic insulation, and thermal control systems are distributed across the vehicle. 


Figure 60. Examples of Heating and Thermal Protection Requirements 

[SLaTS Course -Thermal Systems, 2010] 

Because of these basic requirements for thermal systems design, the thermal system 
influences and interacts with most of the other major subsystems. For example, how we fly the 
trajectory, implement control logic for load relief, etc. can drive the thermal environments and 
complicate the thermal system design. In many cases thermal is one of the drivers in the 
selection of materials such as turbine blades and impellers. It is the task of the chief 
engineer/designer and the project manager to see that the system is balanced among all the 
subsystems. The task requires that they have an understanding of the major drivers of each of 
these subsystems. 

e. Avionics 

We usually think of avionics as a combination of black boxes connected together 
electrically that magically make things work. If a launch vehicle (LV) were a human body, 
avionics would be the brain and central nervous system. 

The avionics subsystems consists of electrical power systems (EPS), radio 
communications, electromagnetic environmental effects (E3), command and data handling, 
sensors and instrumentation, flight software, and range safety. Some of the key issues within 
each of these subsystems are functionality of the subsystem, cost, reliability, heat rejection, 
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communications, location, mass, and volume. In the design of the avionics system, interactions 
and interdependencies are critical design challenges. 

Figure 61 delineates the Avionics subsystems. The following is an overview of typical 
activities associated with various subsystems: 

a. Electrical Power Systems provide batteries and power conditioning needed to satisfy 
various requirements along with verification. 

b. Radio Communications provide data transfer, time space position tracking (TSPT), 
range safety/ flight termination system, voice for crewed vehicles, and video through 
frequency management. 

c. Electro Magnetic Environmental Effects (E3) 

1 . Radiated Emissions - limits EMR so no interference with on-board receivers. 

2. Radiated Susceptibility - defines limits so equipment will not experience 
interference from RF transmitters. 

3. Conducted Emissions - limits noise to platform power bus. 

4. Conduct Susceptibility - defines immunity level to preclude interference from 
power bus noise. 

d. Command and Data Handling defines vehicle mode or mission phase of vehicle 
software, data command processing and distribution, vehicle timekeeping, data-bus 
management, formatting telemetry, and data storage. 

e. Sensors and Instrumentation implements requirements to sense a stimulus then 
converts it to electrical response which results in an output voltage and then 
converts it to counts. 

f. Software developed for flight, ground, and simulations. 

g. Range Safety provides range limit lines, flight termination system, and 
pyrotechnic locations. 


Avionics 





Avionics SE&I 
(aka Integrated Avionics) 


Electrical 

Power 

Systems 



E3 


Command 
& Data 
Handling 


Sensors 
& Instru- 
mentation 


Flight 

Software 



Avionics Subsystems are Electrical Power Systems (EPS), 
Radio Communications, Electro Magnetic Environmental 
Effects (E3), Command and Data Handling, Sensors & 
Instrumentation, Flight Software, and Range Safety. 
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Figure 61 . The Functions and Subsystems of Avionics 

[SLaTS Course, Avionics, 2010] 



The avionics design function includes responsibility for designing the electrical and 
electronic hardware and software that comprise the avionics system for the vehicle and all the 
supporting systems as well as all payloads, satellites etc. Therefore it is both the flight systems 
and the ground support and checkout systems. Typical flight hardware components include the 
vehicle flight computer, power distribution and control unit, telemetry computers, battery units, 
inertial navigation system, global positioning system, transmitters, receivers, video cameras 
and processors, instrumentation, sensors, signal conditioners, cabling, power conditioners, 
power distributors, rate gyros, and actuator controls, some as indicated on Figure 62 


Launch Abort System 
Orion 

Crew Exploration Vehicle ^ 


Spacecraft Adapter 


Upper Stage < 


I 


J-2X Upper Stage 
Engine 


First Stage 
Forward Skirt 


First Stage 
Aft Skirt 




First Stage < 


Ares I 



Instrumentation Unit 

• FlightComputers 

• Radio Frequency Communication System 

• Command & Telemetry Computers 

• Flight Safety System 

• Data Acqu isition & Control Units 

• Battery Unit 

• Power Distribution & Control Unit 

• Inertial Navigation System 

• Developmental Flight Instrumentation 

• Operational Flight Instrumentation AftSkirt 

• Global Positioning System . Combined Contro | System 

Electronics 
Battery Unit 
Power Distribution & 
Control Unit 
Developmental Flight 
Instrumentation 
Operational Flight 
Instrumentation 
• DataAcqu isition & Control 
Unit 

Interstage 

• Rate Gyro Assemblies 

• Roll Control System Electronics 

• Battery Unit 

• Power Distribution & Control Unit 

• Pump Motor Inverter Unit 

• Developmental Flight Instrumentation 

• Operational Flight Instrumentation 



Figure 62. Typical Avionics Components of a Typical Launch Vehicle 

[SLaTS Course - Avionics, 2010] 


The avionics design function involves the synthesis of the avionics system to meet 
requirements in two general categories: 

(1 ) Performance of the electrical/electronic systems and 

(2) Resource and interface requirements, including cost, reliability, weight, power use, 
volume, and thermal conditions. 

The design of the avionics system involves interactions with disciplines in other design 
functions including the systems design function. Interaction with the systems design function is 
vital in determining the requirements for the avionics system. See Figure 63. The systems 
technical integrator establishes the aforementioned general categories of requirements. 

Internal to the avionics design function is the avionics system engineering and integration 
discipline. This discipline is responsible for understanding the requirements for avionics from 
the systems technical integrator and deriving the more detailed avionics system requirements. 
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Requirements are allocated and analyses and trade studies are performed. Reliability 
requirements are considered together with weight, power, volume, and cost to determine the 
appropriate level of redundancy and redundancy management which is a major driver in 
avionics complexity. From these requirements, the avionics system architecture is defined. All 
disciplines within the avionics design function are involved in the architecture definition, but the 
avionics systems discipline is responsible for assuring that the architecture will meet the 
overall requirements and constraints. Component requirements and constraints are derived 
and an electrical, electronic, and electromagnetic (EEE) parts plan is developed. 

An important factor at the time of the architecture definition is the determination of the 
means and extent of verification of the avionics system. Packaging to accommodate the 
environments is designed, and estimates are made of the power, weight, volume, and thermal 
characteristics. The collected attributes of the preliminary design are then compared with the 
avionics requirements and constraints, and the design is iterated until satisfactory convergence 
or relief from requirements is sought from the systems technical integrator. 



Figure 63. The Major Interactions and Design Flow of the Avionics System 

[NASA TP-2001 -21 0992, Avionics - Atherton et. al., 2001] 

Two examples of the application of Avionics subsystems are given below. The first 
pertains to how the hardware and software are applied for the navigation and guidance 
system. The Avionics subsystems receive signals from the vehicle’s sensors, process the 
signal data, and send commands to the rest of the vehicle, telling subsystems what to do, and 
informing the ground of what it is doing. Another way to say this is that avionics provides the 
means in telling the launch vehicle where to go, what to do, checks how it’s working, and 
reports back to the ground system. 
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The second example is the Space Shuttle SRB RF links as shown in Figure 64. It can 
be seen that it includes radar tracking, telemetry, satellite and voice communications, and 
range safety. 





TDRS 
Satellite Constellation 



Telemetry 

Up/Down 


TV 



Left SRB 
Radar Tracking 


GPS Satellite Constellation 



Figure 64. The Space Shuttle Communications System Typical RF Links 

[SLaTS Course - Avionics, 2010] 

Figures 64 and 65 delineate the inputs, tasks and outputs of two major subsystems of 
the Avionics system. Figure 65 is an illustration for a typical Communications and Data 
Handling System and Figure 66 is for a typical Power System. These figures illustrate the level 
of complexity and required interactions it achieve a flight certified design. 
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Figure 65. Inputs, Tasks and Outputs of a Typical Communications and Data Handling 

System 

[Humphries et. al., 1999] 
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Figure 66. Inputs, Tasks and Outputs of a Typical Power System 

[Humphries et. al., 1999] 


3. Interfaces and System Design 

a. Interfaces 

As was stated in an earlier section, designing for and managing interfaces is one of the 
keys to successful space products. The process starts with requirements that are derived to 
minimize the number and complexity of the interfaces and their functions. In order to 
accomplish the requirements definition activity, we must first determine what interfaces are. 
Most have no problem in thinking of hardware/software type interfaces that include structure, 
mechanisms, electrical, and fluids, but interface management is much larger than these. In 
fact, just to properly manage the hardware/software interfaces requires additional types of 
interfaces that must be properly managed. These interfaces take the forms of information, 
models, organizations, etc. and require the same rigor and control as the hardware interfaces. 
They too must be designed to minimize the number and complexity of the interfaces and 
interactions that are required to satisfy their functions efficiently. All interfaces must be under a 
strict verification approach and a very stringent configuration control. The success of a project 
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depends on the efficient selection and design of the total set of interfaces as a fundamental 
part of a system. We don’t want to end up as the following cartoon shows (Figure 67), but want 
to end up as a uniform successful operating, coupled system. 



Figure 67. Example of Poor Interface Management 

Figure 68 shows some of the interfaces between a flight computer and other onboard 
and ground systems. It is illustrative of the many interfaces among space systems, ground 
systems, and crew. It is obvious that these interfaces are not only electronic etc. but are very 
human driven. This means that managing of interfaces not only includes the hardware and 
software but all the people involved, greatly complicating the management task. Designing for 
the human/machine interfaces is in all probability the most complex task. Since so much of 
modern technology is driven by computers that require human interfaces, this becomes one of 
the key design drivers. In summary, designing, building, verifying and configuration control of 
interfaces is one of the major tasks the project manager and technical integrator faces and 
project success depends on its execution. 
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Figure 68. Typical Spacecraft Interfaces with Ground Systems 
b. Rebalancing the System 

When we upgrade the design of a subsystem we cannot just hand it back to the system 
and move on. The results of the subsystem design iteration must be integrated into the 
system. This reintegration in general will uncover additional interactions as the subsystem 
interfaces with and interacts with all the other subsystems that make up the composite system. 
When this is accomplished we find that the subsystem and the system do not act as they did 
before the changes. In other words there are no small changes. As was illustrated on the 
previous Figure 47, these interactions cause the system to have to be rebalanced and can 
result in changes to the derived requirements and/or fine tuning of each of the subsystems in 
order to reach an acceptable compromise to the system characteristics. This iterative process 
of rebalancing the system is a major task that requires the special attention of the project 
manager and the technical integrator. 


D. Lifecycle Activities Following Detail Design Phase 

1. Materials and Manufacturing 

Materials selection, materials characterization, and manufacturing are central aspects of 
project development and require great attention of both the program/project managers and 
engineering to ensure process control, quality, schedule and cost goals. The level of material 
characterization heavily influences the selection of materials. We ultimately must select 
materials by considering the operational requirements (environments, natural and induced) 
and the engineering properties of the candidate materials. Typical requirements include, but 
are not limited to, application, operational environment transient or steady-state, static or 
dynamic loads, temperature, chemistry, contamination, life expectancy, and induced and 
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natural environments. After we understand them, then we must match the requirements with 
particular engineering properties of the candidate materials which may include 

• Mechanical properties (strength, toughness, thermal expansion etc.) 

• Chemical properties (corrosion, flammability, toxicity etc.) 

• Physical properties (density, specific heat, thermal expansion etc.) 

• Compatibility with manufacturing methods (heat treating, tempering, surface 
treatment, joining) 

• Compatibility with other materials 

• Compatibility with test and inspection processes 

• Availability 

• Cost 

In most cases, we must relate the candidate materials to each other by using 
combinations of the resulting properties, For example, when dealing with launch vehicle 
design, strength-to-weight ratios of candidate materials become extremely important because 
of the inherent need for lightweight, high-strength materials. Figure 69 illustrates the basic 
roles of materials and manufacturing. 


The manufacturing process is a set of 
logical steps that are iterated to build the 
desired product 
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Figure 69. The Roles of Materials and Manufacturing 

[SLaTS Course - Materials & Manufacturing, 2010] 


Figure 70 illustrates the basic process for materials and manufacturing showing that it is 
a building block approach that starts with a literature search and proceeds to material 
characterization, material selection, manufacturing process selection and manufacturing. The 
manufacturing process and the built hardware then must be verified through test and analysis 
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that it can meet the operational requirements under all predicted natural and induced 
environments. Material selection, manufacturing and verification are essential tasks that 
project managers must understand and manage.. The role of verification operations is 
discussed next. 

Materials and manufacturing engineers make decisions and develop procedures 
that take the vehicle from the design stage to actual flight hardware. 
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Figure 70. Process in Materials and Manufacturing 

[SLaTS Course - Materials & Manufacturing, 2010] 

2. Verification & Validation (V&V) 

Verification and validation are a fundamental part of technical integration that must start 
with concept development and continue throughout the program in some form or level. We can 
achieve verification through test, analysis, demonstration, inspection, or similarity engineering, 
using these methods individually or in combination. Verification is the process whereby we 
demonstrate that a system can meet its specified requirements. Verification is always a major 
cost item, as well as an influence on other key system attributes such as weight and power. 
We verify design at the component, the subsystem, and the system levels. As a result, the 
systems engineering team must develop a top level verification plan with the support of all the 
design function engineers. A general set of definitions for the V&V function is: 

• Verification - Proof, by examination of objective evidence, that the product complies 
with specifications. Verification is performed to ensure the product complies with 
requirements and may be determined by test, analysis, demonstration, inspection, 
similarity or a combination of these. 
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• Validation - Proof, by examination of objective evidence, that the product accomplishes 
the intended purpose. Validation is performed to ensure that the product is ready for a 
particular use, function, or mission and may be determined by test, analysis, 
demonstration, or a combination of these. 


• Acceptance - A process performed to ensure all articles and materials meet the 
specified program/project quality requirements as documented and released through 
the approved program configuration management plan. This includes the closure of all 
applicable nonconformance reports and approval of all deviations and waivers. 

• Accreditation - The official certification indicating that a model or simulation is 
acceptable for use for a specific purpose. 

• Certification - (a) A written guarantee that a system or component complies with its 
specified requirements and is acceptable for operational use. (b) The formal written act 
whereby a responsible official attests to the satisfactory accomplishment of specified 
activities and authorizes the specified hardware/software, procedures, facilities and/or 
personnel for program usage. 

Figure 71 illustrates an alternate way of looking at verification and validation showing 
that we start with what the user needs and what we build, then show that we built it right 
(verification) and that we built the right thing (validation). With this we verify requirements and 
validate expectations. 


What does the 
user need? 


build? 



Figure 71. The Vee Diagram for Verification 

Figure 72 is intended to show the process starting with requirements and then building 
the verification/validation objectives and plans. These use analysis, test and simulations to 
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mitigate the risks associated with the product. Since test is one of the major cost drivers of 
verification the right hand side of the chart emphasizes the test objectives, events, test 
requirements and test procedures. 
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Figure 72. Verification Process Flow 

[SLaTS Course - Verification and Validation, 2010] 


The following defines the type of tests we do and what their objectives are. 


1 . Development Tests : Provide confidence in design 

- Verify new technologies 

- Assess environments 

- Determine performance 

- Anchor models 

- Establish sensitivities, uncertainties and margins 

- Develop manufacturing processes 

- Uncover unknowns 

Development tests are conducted throughout the design cycle of a project and are used to get 
basic information about the characteristics of the system, so that the design incorporates these 
characteristics and can handle the situations induced. Development tests include wind tunnel 
testing, scale model dynamic testing, thermal testing, materials testing, component vibration 
testing, acoustical testing, full scale testing of engines and other elements, etc. and are 
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fundamental in understanding the systems. Component vibration tests and thermal vacuum 
tests uncover design flaws that can be corrected before final design is completed. 

2. Qualification Tests : Flight-type hardware is verified to perform in severe conditions (3 a) to 
demonstrate margins 

- Elements, subsystems, components, ... 

- Hydraulics, pneumatics, mechanisms, ... 

- Vibration and acoustics 

- Thermal vacuum 

- Hardware simulation labs 

- Materials characterization 

Qualification tests are generally of flight type or flight hardware that are tested to at least 3 
sigma levels of the environments with the component carrying out certain flight type functions. 
Minor changes are easily made after these tests and if changes are required, the tests are 
generally repeated. 

3. Certification Tests : Provide confidence that hardware is ready to go into production 

- Verify system performance, durability 

- Verify manufacturing and assembly processes 

-- Workmanship 
- Manufacturing instructions 

- Line replaceable unit process 

Certification tests are usually for things like liquid propulsion system engines that can be 
ground tested under flight-like conditions using both flight hardware and flight operational 
procedures. For example certification of the Space Shuttle Main Engines required that two 
identical engines be tested under flight profiles and operational procedures for 20,000 seconds 
each. Some of the major problems experienced during certification testing will require either 
hardware changes and a repeat of the certification testing or flying the system under waivers 
and operational constraints. 

4. Process Assurance Tests : Provide confidence in continued acceptability of production 
process by sampling and testing from production runs 

- Solid rocket motor firings 

- Pyrotechnics tests 

Process assurance tests are generally for solid rocket motors and pyrotechnic devices. 
Hardware like this is either very costly or is destroyed in the tests so lifecycle testing is not 
appropriate. The test program usually consists of a few (say 5) motors or devices before flight. 
During the operational program, a motor or device is periodically pulled from the manufacturing 
line and tested to ensure that the build process is still meeting requirements. 

5. Acceptance Tests : Demonstrate end item will meet design and performance requirements 
for a specified mission 

- Components and systems 

- Green run tests 

- Wet flight readiness test 
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Acceptance tests are usually of avionics and mechanisms where each unit is tested when it 
comes off the production line. The tests are not of full flight duration and are at reduced 
environments. This testing is to eliminate manufacturing or infant mortality flaws. Flight liquid 
propulsion engines are tested in this manner using a short duration hot firing of the engine. At 
various times in space programs the engines attached to flight stages are ground hot fired for 
short durations to understand the interaction of the engines with the main propulsion systems. 

6. Systems Integration and Verification Tests : Demonstrate that integrated system’s physical, 
functional, and informational interface requirements are satisfied. 

Integrated tests are of many types to either validate analytical models or to obtain basic natural 
and induced environments. The following is a partial list of integrated tests for launch vehicles. 

- Integrated ground vibration (dynamic) tests to validate dynamic models 

- Main propulsion tests to understand the integration of engines with the main 
propulsion system elements and software 

- Wind tunnel testing for static aerodynamic characteristics, aeroelastic testing to 
determine elastic body effects on aerodynamics, acoustical testing to 
determine aeroacoustic environments, aerothermal testing to determine 
heating environments, etc. 

7. Flight Readiness Firing : Demonstrate integrated system will meet key on-pad requirements 
during engine firing. We can do Flight Readiness Firings on the launch pad, of short duration 
burn time, of launch systems with liquid propulsion systems. This is done to check out the MPS 
after any major changes made from prior configurations. 

8. Other tests : 

- Development test flights 

- Post-flight tests 

Flight test programs of launch vehicles are typically the first two or three flights that are heavily 
instrumented in order to determine combined environments and interactions that are that are 
not possible to accomplish in the previously discussed tests. Flight testing has uncovered 
many major problems that were not found during prior tests. Post-flight tests are done to 
assess the condition of recovered hardware after its use. 

Implementation of verification and validation is a very costly part of any space program 
or project. For example a liquid engine that is started in space requires a highly specialized 
test facility that simulates the vacuum conditions of space. The Ares I launch vehicle was to 
use for its second stage a derivative engine of the original J-2, named J-2X. It required an in- 
space start, and a major facility to develop this capability. A new facility is being constructed 
that can accomplish this task. Figure 73 is a pictorial of the facility with some of its 
characteristics. 
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Figure 73. Vacuum Liquid Engine Test Facility 

[SLaTS Course - Verification and Validation, 2010] 

Many other special facilities are needed for verification and validation of any space 
system and consist of facilities for structural testing, thermal testing, aerodynamic testing, 
software testing, vibration testing etc. Prioritizing and managing these systems is one of the 
major tasks of a project manager. 

In summary, what does all this verification and validation process mean to a project 
manager? The following list provides a quick summary of the requirements. 

• All analytical models/tools must be validated 

• All design and operational data must be validated 

• Components must have development, qualification and acceptance testing 

• System/subsystem capability must be verified 

• Solid motors must have development and process assurance testing 

• Liquid engines must be certified 

• All interfaces must be verified 

• Software must be validated and certified 

• Final checkout must be confirmed 

• Integrated system must be verified and validated 

Successful completion of the process means that the product meets requirements and will 
operate to meet its intended purpose. 

Not only must V&V verify and validate the final product but must verify and validate the 
manufacturing process, the transportation system, operational system, etc. The V&V process 
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requires the best management skills a project manager can muster and is one of the key 
secrets to program success. 


3. Operations 

Options for field and flight operations concepts are nearly unlimited. Choosing a 
practical, cost-effective approach is crucial to achieving economical operations of our space 
systems. Quoting from the Space Launch and Transportation System (SLaTS) book: [Larsen 
2008] “A simple plea: as operators assigned to a launch vehicle design team we must 
contribute to the design process from the beginning. We need to provide serious engineering 
input in the form of prior analysis and we need to bring our planning tools. The process steps 
in this section describe the first iteration in the concept exploration and early concept definition 
phases. Similarly, the engineering design team must bring the operations specialist to the table 
early, to avoid designing a vehicle that is inherently difficult to operate and support. The team 
can’t wait for their concept to be “assessed,” quite probably misunderstood, and subsequently 
dismissed. They may be seeking only commitment for a vehicle design, but the ultimate 
decision makers, somewhere down the road, must make a larger commitment than just a 
vehicle. They must commit to space transportation architecture, complete with facilities and 
support infrastructure, an operational workforce, and a logistic supply chain.” 

KSC did an Access to Space study in 1994 that identified drivers in the direct and 
indirect cost of space operations for a launch vehicle that is shown on Figure 74. The major 
cost is not in the visible, direct tasks but is in the indirect hidden tasks. As this study shows, the 
launch vehicle must be designed along with the operational system to reduce these hidden 
costs. Accomplishing this is a major management task. 
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Figure 74. The Cost of Operations by Operational Functions 

[Kennedy Space Center, 1994] 

Figure 75, another KSC study result, shows the manpower spent on operations for the 
Space Shuttle, categorized by vehicle subsystems. Notice that thermal protection systems and 
propulsion systems and their fluids are the big drivers in manpower. To reduce cost of 
operations the design effort must focus on the areas of high manpower. It is a very complex 
management task that balances the systems between performance, operations, cost, and 
other -ilities. 
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Figure 75. Space Shuttle Operational Man-hours by Subsystems 

[Kennedy Space Center, 1994] 


Transportation of hardware from the manufacturing facilities to the launch facilities is 
another operational cost driver. Figure 76 is a pictorial of the various types of transportation 
used today. 



Water Transport 


Figure 76. Modes of Transportation for Space Systems 

[SLaTS Course - Operations, 2010] 
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E. Decision Making 

We have looked at many aspects of designing space systems and space launch 
vehicles. Putting all these pieces together requires making decisions that best balance the 
system technically and programmatically. This is a foreboding task that we must attack in a 
logical and effective manner. As was stated earlier in the report we accomplish the decision 
making task by: 

• Understanding and quantifying uncertainties and sensitivities 

• Determining and allocating margins 

• Defining, managing and mitigating risks. 

• Balancing the system (Making the key decisions) 

1. Understanding and Quantifying Uncertainties and Sensitivities 

In the design of complex systems there are always top level requirements, constraints, 
ground rules, and assumptions that set the stage for accomplishing the design. It is the 
designer’s challenge to figure out how to strike balance among them. Included in the art of 
design is knowing how to apply sensitivities, uncertainties, and margins to achieve the best 
balanced design with confidence. As we have emphasized throughout this report, sensitivity 
analysis is a key tool to achieve the best balance among the design’s attributes. This is 
accomplished by assessing the changes in the attributes that result from changes in the design 
variables. This produces the sensitivity factors (partial derivatives). It enables the designer to 
iteratively converge the design and involves the application of analysis, test, and simulations. 
Uncertainty pertains to random variations in design input variables at all levels and the 
corresponding random variations in the design attributes (outputs). These variations are about 
mean values and are determined via historical data bases, tests, and expert opinions. Margin 
pertains to the difference between some measure of capability and some measure of demand. 
Understanding uncertainties and application of adequate margins throughout the various 
stages of the project provide the necessary confidence in the design of systems with high 
power densities. The uncertainties can be categorized as epistemic and aleatory uncertainties. 
The details of how to handle the different types of uncertainties is left to the reader and is a 
course within itself. 

High performance systems have high sensitivities and uncertainties which complicates 
the design. If a comparison is made between the design efficiency (power/pound) of a rocket 
stage and an airplane, the rocket stage is about two orders of magnitude higher in design 
efficiency. If compared to an automobile, the rocket stage is about three orders of magnitude 
higher. 


Sensitivities and uncertainties have to be determined and assessed through all stages 
of the design process. This requires attention to design detail to assess the best design 
decisions and potential for reducing uncertainty. In fact, uncertainty can in some cases be 
reduced by reducing sensitivities. A major concern in design is determining the uncertainties 
in the output variables in terms of uncertainties in the input variables. Some of the methods 
used to assess these uncertainties are root-sum-square (RSS) and Monte Carlo simulations. 
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In the early phases of design it is important to ensure adequate margins are provided to 
assure headroom for unknown effects of sensitivities and uncertainties. As the design activity 
proceeds every effort must be made to understand sensitivities to achieve the best balanced 
design and to reduce uncertainty to reduce risk and provide design confidence. 

The following is an overview of uncertainty in rocket engine and structural design. In 
rocket engine design, high uncertainty results in high development cost. Figure 77, see 
reference [Havskjold, 2004], illustrates the effect of uncertainty on high cost. The figure on the 
left is the number of rework cycles (corrective actions) as a function of technical uncertainty 
factor for various subsystems. As the uncertainty increases the number of rework cycles 
increases. The uncertainty is a result of high static and dynamic flow induced loads, thermal 
transients and gradients, high pump speeds, welds, etc. In the figure on the right is the cost 
versus the number of years in the development. It can be seen that 73% of the development 
cost is a result of corrective actions (test-fail-fix). In the development of the SSME there were 
38 significant incidents (failures of hardware during test) that cost over $30 million per incident. 


Humber of Corrective Actions Correlated 
With Risk/Uncertaintv Remaining at Start 
of Full Scale Testing 


Development Costs Dominated by 
Rework Cycles After Full Scale Engine 
Testing Begins 



Figure 77. Technical Uncertainty Leads to High Cost 

[Havskjold, 2004] 

Having the experience shown in Figure 77, what can be learned to improve the effects 
of uncertainty? Shown in Figure 78 is an indication of how reducing uncertainty and improving 
processes can reduce development cost. 


93 


Process 
Improvements 


Number Of Corrective Actions 



Cost To Perform 
Corrective Actions 



Technics Uncertainty Factor 


Future Need 


Certified 

Product 


-Explore Design Space 
-Improve Processes 
-Reduce Sensitivities 
and Uncertainties 
-Quantify Risk 


Time 



Figure 78. Combined Effect of Low Uncertainty and Improved Process to Reduce Cost 

[Havskjold, 2004] 


Figure 78 indicates that as the uncertainty is reduced the number of corrective actions 
can be reduced and by process improvements the cost of corrective actions can be improved. 
The net effect will be reduced cost to achieve a certified engine. Uncertainty can be reduced 
by lowering the static and dynamic flow induced loads, e.g. decrease chamber pressure and 
open up flow areas. In addition, uncertainty can be reduced by reducing pump speeds, 
improved definition of environments, etc. Process improvements can be achieved by 
minimizing welds, application of friction stir welding, bonding by high isostatic pressing, 
reduced part count, etc. Overall by building on our experience base and by implementing new 
design technologies as shown in Figure 79, significant cost reductions can be expected in the 
future. 
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Figure 79. Engine Reliability and Standardization 

[Wood, 2002] 


Uncertainty in structural design is illustrated in Figure 80. 





Figure 80. Uncertainty in Structural Design 


In the middle of the figure are the probability density functions (PDF) of the working 
stress and the material allowable. In the region where there is overlap, failures will occur. In 
this example, the design has considered all the failure modes and the failure mode of concern 
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is the strength. The variability in the material allowable can come from the random variations 
as characterized by the right-hand PDF’s and for the stress the variability can come from the 
random variations associated with the PDF’s in the left hand column. Knowing the associated 
PDF’s, the reliability of the design can be determined. In the example shown, the design would 
be unacceptable because of the size of the interference region. Various changes can be made. 
The mean stress can be reduced by reducing the load or changing geometry. The uncertainty 
could be reduced by restricting the uncertainty in the load, changing tolerances, improving 
welding, etc. The material properties can be improved by changing the material to one that has 
a higher allowable or one with less uncertainty or both. 

Sensitivity and uncertainty play important roles in the design of complex systems where 
there are high power densities. Sensitivities provide insights regarding developing the best 
balanced design and also aid in reducing uncertainties. Knowing the uncertainty provides a 
means for assessing risk and provides confidence in the design. Understanding past 
experiences (lessons learned) and applying new design tools provide visions toward design 
improvements to reduce cost in the future. 
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Figure 81. Principles of Uncertainties and Sensitivities 

[SLaTS Course - Sensitivities Uncertainties & Margins, 2010] 

At the lower left of Figure 81 is a graphic representation of the sensitivity of two different 
systems to the same parameter uncertainty. In one case the output is a very small change in 
the response due to the variation of the parameter while in the other the response change is 
very large. The ideal system would be the first curve; however, many times it is not possible to 
get the ideal insensitive system which then means that we must understand the system in 
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more detail. The right hand bottom figure is how we apply margin to the three sigma responses 
to cover additional things that can’t be known and to cover growth as a system matures. 

A principle we learned many years ago in working the numerous SSME problems and 
failures says; the higher the performance requirements the greater the system of the system to 
any parameter uncertainties. All of this high power density and high efficiency comes with a 
price as illustrated on Figure 80 top right corner of chart. This is a generic curve which 
represents a number of different physical systems. For example the structural SN Curve for 
fatigue is the inverse of this curve. A plot of vehicle dry weight versus dry weight margin will 
basically trace this generic curve. What this means then is that as we move out on the 
performance curve, our design, verification and operations efforts go up non-linearly with the 
increase in performance requirements. It means that great attention must be used to design, 
build, verify and operate these high performance systems. 

2. Determining and Allocating Margins 

Understanding the uncertainties and sensitivities forms the basis for adding margins 
to the system during the process of conception and design to account for the unpredictability of 
the system. For example we know that the mass of system grows during design as a function 
of the maturity of the technologies used in the system. Mass margin has a mass growth 
allowance allocation and depletion plan, a mass margin and depletion plan and a program 
mass reserve. This is managed throughout the project life cycle (Figure 82). Each of NASA’s 
projects defines the areas that it will assign and manage margins for, then specifies a process 
for that management. For example, margins are identified for mass, performance, power, 
software, thermal protection, clearance, controllability, communications, launch availability, 
operability, etc. A plan comparable to the one for mass management must be developed for all 
areas where margins are to be assigned. Typical plans for previous projects are available in 
NASA documentation. 
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Classic Mass versus Time Figure 
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Growth Allowance: Amount of predicted growth above the basic resource estimate; 
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Figure 82. Typical Mass Margin Management Aproach for Total Lifecycle 

[SLaTS Course - Margins, 2010] 


3. Defining, Managing and Mitigating Risks 

Risk pertains to situations where there are undesirable and uncertain events that could 
be detrimental or have adverse consequences. In the development of space hardware, risk is 
concerned with the likelihood of occurrence of undesirable end states and the severity of 
resulting consequences. 

Throughout the lifecycle process, various risks of the system must be assessed, 
understood, and managed. These risks are both technical and programmatic. The decision 
making process dictates that we make these decisions based on the total risks of the system. 
Technical risks deal with potential failure modes and their probability of occurring as well as 
the severity of the consequences of the failure. Programmatic risks of cost and schedule are 
similar in their approach. Technical risks have an impact on the programmatic risks and vice- 
versa, as illustrated in Figure 83. 
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Figure 83. Relationships Among Risk Categories 

[SLaTS Course - Risk Assessment, 2010] 


Risk assessment and management guides the design through all stages of the design 
process. In the end, it provides confidence in the final design. Risk assessment pertains to the 
process of identifying and modeling potential risk scenarios, determining the associated 
probablility of a occurrence, the severity of the consequences, and actions required to reduce 
the risk to an acceptable level. Risk management is a process concerned with identifying, 
analyzing, planning, tracking, and controlling risk. 

Concerns relating to risk occur during all stages of the design process. They pertain to 
all categories of risk-- technical , cost, and schedule. The main focuses of technical risk are 
safety (personnel, assets, and environmental) and performance (requirements, operations, and 
supportability). After a risk assessment is accepted it is usually prioritized by a project review 
team. The application of risk assessment and management enables the project to focus on the 
most pressing issues. The project’s goal is to balance all risk categories and bring them to a 
level as low as practically possible. 

Figure 84 provides a risk assessment taxonomy. It can be seen that there are two major 
methods associated with risk assessment. One method deals with risk matrix assessment and 
the other deals with probabilistic risk assessment (PRA). 
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Figure 84. Risk Assessment Taxonomy 

[SLaTS Course - Risk Assessment, 2010] 

The risk matrix method usually applies to project levels 3, 4, and 5. The main purpose is 
to determine and assess undesirable events associated with technical (safety and 
performance), cost, and schedule and includes participation of engineering and S&MA. They 
determine the likelihood of an undesirable event and the corresponding severity. The risk 
assessment then goes to the project team where the priorities are determined. This 
methodology was established in the mid to late 1970’s and continues to be refined to 
accommodate various applications. 

PRA is a method that is usually applied to project levels 2, 3, and 4. This method is 
usually applied to assess events that have a low probability of occurrence, but with enormous 
consequences, for instance: loss of crew, loss of vehicle, or loss of mission. One of the 
distinguishing features of PRA is the determination of uncertainty associated with the risk level. 
As can be seen from the figure the results are represented by a probability density distribution. 
This methodology was developed in the early 1970’s to assess risk associated with nuclear 
reactors. 
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4. Balancing the System (Making the Key Decisions) 

Using the results of the uncertainties, sensitivities, margins, and risks the system must 
be balanced in a best possible manner in respect to performance, the -ilities, cost and 
schedule. This involves making decisions as to the best balance throughout the process. 

Early decisions determine the characteristics that the system will have throughout its life 
cycle. How we make these decisions is obviously one of the keys to product success and is 
therefore a key function of project managers. For example, shown of Figure 85 is the gross 
liftoff weight of the vehicle as a function of the delta-v split between the first and second stage 
of a 2-stage launch vehicle. If weight alone is the driving metric then the delta-v choice would 
be that which gives minimum weight; however, other considerations such as commonality 
might shift the decision away from the minimum weight solution. The number of factors such 
as the delta-v split are complex and become the inputs to the decision making process. 
Decisions usually have impacts on the system that are realized throughout the project life 
cycle. The decisions to select the parallel burn Shuttle configuration and to have it satisfy the 
launch requirements of both the Air Force and NASA had major impacts on the project, 
effected throughout the life cycle. Air Force cross range and payload size drove the Orbiter 
configuration determining the payload bay size and the Orbiter wing configuration. This wing 
configuration in all probability affected the reentry thermal protection system design (tiles). 


Factors in Decision Making 
Example: 2-Stage Sensitivity to Staging Point and Isp 



9000 1 10 4 1.1 10 4 1.2 10 4 1.3 10 4 1.4 10 4 

Delta V by First Stage (fps) 


•The sweet spot of Delta V split is 
shown in the plot of GLOW vs Delta 
V Split showing the large sensitivity 
of GLOW to the 1st stage Delta V . 
•Other factors that must be a part of 
the decision of what Delta V split is 
best: 

•Commonality 

•Reliability 

•Cost 

•Schedule 

•Manufacturability 

•Power Density 


Figure 85. Launch Vehicle Gross Liftoff Weight Versus Delta V Split Between First 

and Second Stage 

[SLaTS Course - Trajectories, 2010] 


The one-and-a-half stage configuration, the lift/drag characteristics and the volume 
geometry drove the SSME to have high power density and high thrust/weight which caused 
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many of the fracture, fatigue and manufacturing problems. As a result, to solve many of these 
problems, the SSME had at least three block changes that included the two duct manifold, the 
large throat powerhead, and the alternate high pressure turbopumps. The parallel burn 
configuration created a system of four bodies connected by struts that created a set of 
complex load paths, very complex dynamics, complex aerodynamic flow paths and complex 
thermal protection systems. The vehicle was very sensitive to small changes that led to very 
detailed and complex analysis and test cycles. As the system matured, several element block 
configuration changes were required to meet the performance and reliability requirements. For 
example the External Tank had two block changes, the Lightweight Tank and the Super 
Lightweight Tank, that together increased Shuttle performance 17,000 pounds. All of this 
resulted in comprehensive and costly V&V and operational impacts. Numerous problems 
occurred that were major impacts to the program, including 

• Overpressure effects 

• STS-1 aerodynamic anomaly 

• 38 major SSME ground test failures 

• Orbiter tile problems 

• Challenger 

• Columbia 

Another example of major decision impacts was increasing the SSME thrust to 104% to 
reduce payload losses on Space Shuttle. This created 


• Numerous fracture, fatigue, wear, loads and instability problems 

• Many engine ground test failures 

• Strict hardware inspection process 

• Stringent clean room requirements 

• 50% fleet leader rule (Factor of two on time in two ground test engines of 
comparable part being flown) 

• Block hardware changes throughout the life cycle 


A fact that we need to constantly remind ourselves in making decisions is that 
everything reacts based on a set of principles as illustrated on the banner below. 




K&mewW eA/e^ythivig' Oy 
by tfae/hwyofPhyyu&CPhyyCcyCy 
broxuleviecL tfr ivichAde/bu&vneAy 
prCvioCpley or^MU^UtX^ynai/ 
principle# etc*. ) 
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Decisions can not violate the laws of physics. Figure 86 is an excerpt from The Cartoon 
Guide to Physics by Larry Gonick and Art Huffman showing examples of some principles of 
physics. 
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Figure 86. Physics Rules, It is the God of Design 

[Gonick & Huffman, 2005] 
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There are many decision process tools that can used to apply the above considerations 
into an assessment to aid in making decisions. Most of them develop a set of metrics of the 
system that include performance, programmatics, etc. These are then weighted and 
comparisons of different options are made. None of these approaches are absolute but they 
can be good guides to aid the decision making process. In the end it is basically the human 
judgment that makes the final decisions, either as an individual or as a team consensus. 


F. Managing the Design 


Nothing in a project continues to run smoothly. We are constantly faced with a set of 
problems that must be managed or decisions made concerning them. Figure 87 is the arc of 
creativity used in problem solving. The process starts by breaking the problem apart and 
putting it back together so that you can take a fresh look at the interfaces. When this is 
accomplished the problem is reformulated and fruitful analogies are visualized. The 
sensitivities are then searched to determine positive order of magnitude changes that could be 
made, always being alert to serendipitous solutions. 



Figure 87. How We Manage the Problem We are Facing in a Project. 
Management of the Design, The Arc of Creativity 

[We have misplaced this reference] 
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It is clear that managing the evolution of design is a very multifaceted and intensive 
activity. There are technical, business, organizational and cultural aspects that must be 
actively addressed. Some of the focus areas related to Engineering the System include: 

• Trades and Balancing 

• Configuration Management 

• Technical Performance Measures and Parameters 

• Growth Allowances and Margins 

• Verification 

• Risks 

• Integration 

In working trades and balancing, management should ensure that 

• All pertinent options are considered 

• Options are assessed on basis of all attributes: performance, -ilities, cost, safety, 
sensitivities, risks and margins 

• Options are chosen that provides best system balance for life cycle 

Configuration management requires significant management attention to ensure consistency 
among the many concurrent activities. Areas that are under Configuration Management 
include: 

• Requirements 

• System / subsystems descriptions and attributes 

• Drawings and specifications 

• Project design data books 

All evolution and changes of the controlled configurations requires much management effort 
and attention to detail. 

Technical Performance Measures (TPMs) are critical and are key performance parameters 
monitored to assess how well design meets requirements as a part of the management 
process. They are: 

• Key indicators used to confirm progress and identify deficiencies that might jeopardize 
meeting a system requirement 

• Product drivers that can have a significant impact on safety, cost, schedule, risk, or 
technical performance 

• Top level; a relatively small set 

• Monitored by comparing the current actual achievement of the parameters with that 
anticipated at the current time and on future dates 

• Reported at management reviews, along with their related margins 

The remaining areas on the list have been previously addressed. 

Not only must the manager deal with the physics of the problem and evolution of the 
design, but must deal with the role the organizations have in the project. 
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G. A Role of the Organization 

Organizations play many key roles in the management of project integration. The first 
major task of the organization is to keep the vision and mission in constant definition and 
focus. As the old saying goes, the vision and mission set the sails and keep the system 
pointed in the right direction. Using the analogy of the fundamentals of space flight one can 
draw some of these management principles that the project manager and the organization 
need to apply to keep things on track. Figure 88 is an example from the GN&C aspects of 
flight. The end point on the curve represents the mission and part of the vision. While flying 
toward this point, disturbances occur which cause deviations of the system from the desired 
path. There is a navigation system that continuously tells the vehicle where it is in space, how 
fast it is going, and the direction it is pointed. The guidance system then takes that information 
and compares where it is versus where it should be. It is very costly to try and go back to the 
original path so the guidance system calculates a new path to the target. Then as the vehicle 
exits the atmosphere with its disturbances, the control system points the vehicle along the new 
path and maintains system stability while following the new guidance path to the target. 

Any project as it moves through its life cycle will encounter many disturbances that 
knock it off course. These can be technical issues, cost, schedules, political changes, etc. The 
first principle then is not to try to get back on the old path, but to create a new path to the vision 
and mission. This retargeting is one of the main tasks of management that requires a 
navigation system to tell it where it is, a guidance system to retarget the path and a control 
system to keep the system stable and pointed in the right direction. 

Retargeting 
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Many times however, due to large external factors or disturbances, retargeting is no 
longer possible and the mission must be aborted. In some cases politics will cancel the original 
mission. Figure 89 illustrates the effects of these type of changes. If the new target is within the 
characteristics of the system then the decision becomes whether you go for it or abort. In the 
case where the mission is canceled a new mission must be planned. There are many 
examples within NASA where programs were moving along and hardware being built when the 
program was canceled, or the program was canceled before the entire individual missions 
were accomplished. Examples include Apollo, X-33, fully reusable shuttle etc. When this 
happens there is much travail unless a new program is quickly inserted to take its place. If the 
program is canceled and no new mission is readily apparent then there is fear and anxiety. It is 
very important that a replacement vision and mission be established as soon as possible to 
alleviate the building of fears, anxiety and internal power plays. 



Figure 89. Target Changes and Potential Impacts 

Figure 90 illustrates that even with a new vision and mission that there is a place 
between the places of the past and the future where there is fear and anxiety present. Once 
the new place is established there occur many rewards such as growth and fulfillment. It is 
mandatory that managers understand this place between the places. Many years in the past 
Dr. Paul Tournier addressed the subject in great detail. The following quotes are taken from his 
book by the title “A Place for You”. 

❖ However, the law we discovered in regard to man’s place remains true: one must first 
have a place in order to be able to leave it. In the same way, one must first have a 
support in order to be able to jump. One cannot jump without a spring-board or some 
solid support from which to take-off. One must start from a strong support in order to 
make a successful jump-even to risk a jump at all. 
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❖ It is one of the laws of life that one stage successfully completed prepares the way for 
the next, while failure in one stage lays in advance a heavy handicap on the next. 

❖ There is a place that must be left before we can find a new place and in between there 
is a place without a place, a place without support, a place which is not a place, since a 
true place is a support. 

❖ In the middle of the way there is a zone of uncertainty in which the mind is divided 
between two contradictory suggestions. 

❖ There is a past security to be lost before we find a new security. No security lasts, 
however solid, just or precious. For it is a law of evolution that tomorrow will not be the 
same as yesterday, and that there results from that difference the anxiety of today, 
since each moment is a middle zone between the past and the future. 


MUST LOSE TO GAIN: TRAPEZE OF GROWTH 
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TO GROW MEANS LOSS - LOSS MEANS MOURNING 
SO THAT NEWNESS CAN COMEJN 


Figure 90. The Trapeze of Growth 

The fundamental question is “How do we manage organizations to achieve project 
success?” The organization can be just as complex as Engineering the System and Technical 
Integration requiring near equal time and effort for each. As a result both have comparable 
roles in achieving project success. Robert Pool in Beyond Engineering: How Society Shapes 
Technology [ Pool, 1997] says: 
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❖ No single person can comprehend the entire workings of, say, a Boeing 747. 

❖ In truly complex systems, no amount of testing or experience will ever uncover all the 
possibilities, so decisions about risky technologies become a matter of how much 
uncertainty one is willing to put up with. 

❖ The defining feature of complex systems is how its parts interact . Furthermore, a 
complex technology generally demands a complex organization to develop, build, and 
operate it, and these complex organizations create yet more difficulties and uncertainty 
- organizational failures often underlie what at first seem to be failures of a technology. 

❖ The safety of complex systems depends not just on their physical characteristics but 
also quite intimately on the people and_ organizations operating the systems. 

The organization must therefore focus on its most important resource, Its People 
Empowerment. There must be organizational and communication simplicity. The use of teams 
such as IPT’s if formed and managed correctly can aid organizational efficiency. The 
organization must have enough control to maintain coherence but not so much as to constrain 
innovation and creativity of its people. Again quoting from Poole’s Beyond Engineering: 

❖ Layered organizational structure, seems to be basic to the effectiveness of 
organization. ...Some groups are bureaucratic and hierarchical, others professional and 
collegial, still others are emergency response. ... Because of complexity, they are best 
decentralized; because of the tight coupling they are best centralized. ...They 
emphasize constant communication - talk-talk-talk far in excess of what would be 
thought useful in normal organizations. The purpose is simple, to avoid mistakes. ... 
Poor communications and misunderstanding, often in the context of a strict chain of 
command, have played a prominent role in many technological disasters. ... Besides 
communications, high-reliability organizations also emphasize active learning , not 
simply the memonzation of procedures . 

H. The Process for Achieving Excellence 

At the request of the Director of Engineering at Marshall Space Flight Center we put 
together a short course on the process for achieving excellence in engineering. The approach 
that was used to derive the principles of engineering excellence is shown on Figure 91 . The 
process began with a study of the major incidents experienced by the authors working for 
NASA. This study was used to develop root causes from technical, organizational and cultural 
considerations. 

The study identified five top root causes that have led to major problems in NASA. They 
are: 


1 . Shifting from engineering “hands on” and “excellence” to “insight/oversight”. 
Lack of ownership. 

2. “Normalization of the deviances”. Not questioning anomalies. 

3. Lack of critical thinking. Over-reliance on procedures and computer codes. 

4. Decentralization of authority. 

5. Organizational and technical complexity. 
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Taking the incidents studied and the resulting root causes led to the development of an 
approach for achieving excellence in engineering. This approach may be divided into three 
elements as illustrated in Figure 91 . First, Technical Understanding and Execution — it is basic 
that what we do in engineering must be technically correct. Second, Partnership with the 
Project — successful products require a positive, productive relationship between Engineering 
and the Project Office. Third, Individual and Organizational Culture — all activities are 
undergirded by the prevailing culture, which must foster the attitudes and behaviors necessary 
for success in producing and operating our complex systems. Figure 92 takes each of the 
three elements and expands them into their main components. These components are 
discussed in detail in a NASA CR yet to be published and are not repeated here. 




Product, Organization & 
Personnel Excellence 



• Technical Understanding 


and Execution 
• Partnership with Project 
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Figure 91. The Process for Excellence in Projects 
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Elements of Engineering Excellence 


Technical Understandingand Execution 

• Understanding the Physics 

• Technical Integration/ T-Model 

• Interactions and Interfaces 

• Sensitivity, Uncertainty, Margins 



Partnership With Project 


Individual & Organizational Culture 

• Technical Authority 


• Ownership and Accountability 

• Requirements Management 


• Critical Thinkingvs. Procedures 

• Risk Management 


• Right People in Right Places 

• Cooperative Solutions 


• Learning Organization 


Figure 92. Elements of Engineering Excellence 
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V. Summary and Conclusion 

The report has addressed Engineering the System and Technical Integration defining them 
as: 


• Engineering the System: The overall development of a successful product that meets 
project challenges. 

• Technical Integration: The integration of Design and Analysis, Hardware and Software, 
Operations, and Classical System Engineering along with interactions of Business, 
External Relations, Operating Environment and other functions to create a system with 
acceptable performance that is safe, reliable, and affordable. 

Discussed was the challenge of space flight and the process whereby we can meet the 
challenge by Engineering the System. Technical Integration was seen as the overarching 
function that encompasses functions of Classical Systems Engineering, Design Analysis and 
Test, Manufacturing and Verification and Operations. A process for Technical Integration was 
defined that applies understanding of uncertainties, sensitivities, interactions and margins in 
trading requirements and attributes to achieve a balanced design. The trades and 
compromises are directed toward the goal of obtaining the best balance among performance, 
the -ilities, and affordability/cost while achieving necessary safety. Managing the design 
process was discussed with the conclusion that management and organization aspects are as 
complex as the design process itself. 
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CoruZu&uyn/ 

Integration or not? 



[Eddy, 1962] 

"This Is Something For The Home Office To Straighten Out " 


No! This is something for engineering & project to 
solve 6y didgent planning, using a integration 
approach, hasedon uncertainties, sensitivities, 
interactions and risks. 

Integration is every body's j oh. 


Figure 93. Does the Project Apply Engineering the System and Technical Integration? 

Does the Project apply Engineering the System and Technical Integration? If not then 
the cartoon becomes our situation. Hopefully by applying the principles discussed in this report 
we won’t get in over our heads. 
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[Pvt. Hazard by Jim Boroch] 
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